Jupyter Notebooks
Interactive computing environment for data analysis, visualization, and documentation in one document.
What should journalists know about Jupyter Notebooks?
Jupyter is the standard for reproducible data journalism, and nothing else comes close for showing your work. You mix code, output, charts, and narrative text in a single document. BuzzFeed News published notebooks alongside their tennis match-fixing investigation. The Markup built analyses of algorithmic accountability in them. ProPublica starts or ends most major investigations with computational notebooks. The tool earned that trust because it runs locally — your data never leaves your machine unless you send it somewhere. The learning curve is steep: you need Python or R fluency, and notebook state management trips up even experienced users (cells execute out of order, hidden state persists between runs). JupyterLab 4.5 is the recommended interface now — multi-panel layout, built-in terminal, Git integration, code folding, and cell windowing for large notebooks. Classic Notebook 7 still works but is built on JupyterLab components and has a smaller extension ecosystem. For journalists handling sensitive datasets — leaked documents, surveillance records, source communications — local Jupyter is the right call over any cloud notebook. Google Colab is convenient but sends your data to Google's servers and subjects it to their terms of service.
Reproducible data analysis for investigative stories. Publishing methodology alongside findings for transparency. Exploratory analysis of FOIA data, campaign finance records, court documents, and public datasets. Teaching computational journalism. Building shareable analysis pipelines that other reporters can verify and extend.
Journalists who don't write code — use Datawrapper or Flourish instead. Quick charts for publication (overkill for simple visualizations). Real-time dashboards or production data pipelines. Collaborative editing with non-technical colleagues (Google Colab handles that better, with the privacy tradeoffs). Anything requiring GPUs for machine learning — you'll need Colab, a cloud VM, or local GPU hardware.
Security & Privacy
Data is scrambled while being sent to their servers
Data is scrambled when stored on their servers
Where servers are located — affects which governments can request your data
Privacy policy summary
Jupyter itself is local software that sends no telemetry and collects no data. Your notebooks, code, and data stay on your machine. The Jupyter project website uses Plausible analytics (privacy-focused, no cookies). Hosted services are different: Google Colab notebooks live in Google Drive and are subject to Google's privacy policy. Colab VMs are isolated and deleted on session close, but Google employees with elevated permissions could theoretically access data. JupyterHub deployments inherit the privacy posture of whoever runs the server.
How to protect yourself:
Run Jupyter locally for any sensitive reporting — leaked documents, source identities, surveillance data. Never upload investigative datasets to Google Colab or other cloud notebooks. Strip cell outputs before committing notebooks to Git (use nbstripout as a pre-commit hook) — outputs can leak data, API keys, or file paths. Use virtual environments (venv or conda) to isolate project dependencies. Pin package versions in requirements.txt for reproducibility. Set a Jupyter password or token (enabled by default since Notebook 4.3) — an unprotected local server is accessible to any process on your machine. Don't run untrusted notebooks without reading the code first: notebooks execute arbitrary code, and malicious notebooks have been used for supply-chain attacks. Disable JavaScript output rendering in untrusted notebooks to block XSS vectors.
Open-source, runs locally, no telemetry or data collection. The security model is sound when used as intended: local execution, password/token-protected server, trusted notebooks only. The risk surface comes from two directions. First, notebooks execute arbitrary code by design — opening an untrusted .ipynb file is equivalent to running an unknown script. Second, historical vulnerabilities (XSS-to-RCE, config file injection, server proxy auth bypass) show the project has had real security gaps, though they've been patched. Cloud-hosted alternatives like Google Colab introduce data jurisdiction and privacy risks that local Jupyter avoids entirely. Rating: adequate for local use with basic precautions. Would be 'strong' if Jupyter had sandboxed execution or mandatory code signing, but that's not how notebooks work.
Who Owns This
Known issues
CVE-2025-53000: Arbitrary code execution via Jupyter configuration files (config files are valid Python). Jupyter Server Proxy before 3.2.3/4.1.1: unauthenticated websocket proxying enabled remote code execution via phishing links. Historical XSS-to-RCE chain (CVE-2021-32797/32798): malicious .ipynb files could execute arbitrary code through markdown cell injection. Jupyter had 8 security vulnerabilities published in 2024, 3 specific to Notebook. Notebook state management is a persistent usability hazard: cells can run out of order, variables persist invisibly between executions, and 'restart kernel and run all' is the only reliable way to verify a notebook produces correct results. Large notebooks (1000+ cells) cause performance degradation even with JupyterLab 4.5's contentVisibility windowing.
Pricing
Free. JupyterLab 4.5 (current stable, March 2026) and Notebook 7.5 install via pip or conda at no cost. Google Colab is free for basic use; Colab Pro starts at $10/month for longer runtimes and better GPUs.
This is an editorial assessment based on publicly available information as of 2026-04-02, using our published methodology. Independent security review is pending. Security posture can change at any time. This is not a guarantee of safety.
Something wrong or outdated? Report it.