Jupyter — Interactive Notebooks for Data Analysis

What Jupyter is

A Jupyter notebook is a document containing executable code cells and Markdown prose cells, interleaved, with each cell’s output — numbers, tables, plots — displayed inline beneath it. JupyterLab is the modern interface: a file browser, terminal, editor, and several notebooks side by side.

The design insight is that exploratory analysis is a narrative, and the traditional split between the script and the write-up loses it. In a notebook the reasoning, the code that tested it, and the figure that resulted sit in one artefact in the order you thought them. That is genuinely valuable and it is why notebooks took over data analysis. It also introduces the failure mode that defines the format: cells can be run in any order, so what you see is not necessarily what a fresh run produces. Everything good and bad about Jupyter descends from those two facts.

Why researchers use it

Results appear where you are looking — the plot lands under the code that made it, so the iteration loop is tight and the reasoning stays visible.
The narrative survives — six months later, the Markdown cells tell you why you did what you did, which a bare script never does.
Language-agnostic — kernels for Python, R, Julia, and dozens more, in the same interface.
A shareable artefact — notebooks render on GitHub and export via nbconvert to HTML, PDF, or slides, which makes them plausible supplementary material.
The ecosystem around it — ipywidgets for interactive parameter exploration, Jupyter Book for full course websites, Jupytext for plain-text versions.

Where it fits in a research workflow

Jupyter belongs to the exploratory phase — the part where you do not yet know what the analysis is. Its natural end is a decision: either the notebook becomes the communication artefact, or the logic in it graduates into a script or package and the notebook becomes the thing that explains it.

Downstream, that division matters. For a pipeline that must run reproducibly, move the code into modules a Snakemake workflow or a script can call; for a document that renders to PDF or HTML with executable code inside, Quarto is the better format because it is plain text and diffs cleanly. Upstream, run it inside a uv or conda environment; use Google Colab when you need a GPU or a zero-setup link for students; and pair with Jupytext so a plain-text version lives in Git alongside the .ipynb.

Getting started

Half an hour, plus one habit that decides whether your notebooks are trustworthy.

Install JupyterLab into a project environment — uv add jupyterlab or conda install jupyterlab — rather than globally. Notebooks that use a different environment than your scripts are a category of bug you can simply avoid.
Work in a real analysis: load data, plot something, write a Markdown cell explaining what you saw. The interleaving is the whole point and only makes sense in practice.
Set up Jupytext so each notebook has a paired .py or .md file. That file is what Git can actually diff, and it turns notebook version control from painful to normal.
The step people skip, and the one that matters most: Restart Kernel and Run All Cells before you trust any result or share any notebook. It is the only way to know that what you are looking at is what the code actually produces in order.

Jupyter vs the alternatives

Alternative	Does it better	Pick it if
Google Colab	Zero setup and free GPUs	You are teaching, or need acceleration you do not own
Quarto	Plain-text source, clean diffs, publication-quality output	The output is a document, not an exploration
RStudio	R-first interactive work with an environment inspector	R is your primary language
A plain script	Guaranteed top-to-bottom execution order	The analysis is settled and must run reliably

That last row is the honest one. Notebooks are for figuring out; scripts are for running. Confusing the two is where reproducibility problems begin.

Cost, licensing, and your data

Free and open source under a BSD licence, governed by Project Jupyter and NumFOCUS — a genuinely community-run stewardship model, which is a reasonable basis for depending on it long-term. There is no paid tier and no account.

Everything runs locally by default, so there is no third party in the loop. Two practical cautions. Notebook files store outputs inside them, which means a .ipynb you share can contain data extracts, participant identifiers, or file paths from your machine that you did not intend to publish — clear outputs before sharing anything sensitive. And a running Jupyter server is a web server on your machine that can execute arbitrary code; on a shared or institutional network, make sure it is bound to localhost and token-protected, which the defaults do but custom configurations sometimes undo.

The honest review

Strengths. Nothing else makes the iteration loop as tight for exploratory analysis, and nothing else preserves the reasoning alongside the result as naturally. The narrative property is undervalued: a notebook you return to after six months tells you what you were thinking, and a script does not. For teaching and for supplementary material, an executable document that a reader can run is straightforwardly better than a listing they cannot.

Limitations. Hidden state is the defining flaw and it is not minor. Cells run in whatever order you clicked them, variables persist after their defining cell is deleted, and a notebook can display perfectly coherent results that no fresh execution reproduces — a reproducibility failure that looks exactly like success. Version control is genuinely bad without Jupytext, because the JSON format diffs unreadably and outputs create noise in every commit. Notebooks encourage sprawl, so analysis logic ends up copy-pasted across five files rather than factored into a module. And they are poor at anything long-running: no scheduling, awkward parameterisation, and a browser tab that must stay open.

Verdict. Adopt it for exploratory analysis and teaching, which is most of what it is for. Skip it for production pipelines, for anything long-running, and for code that other code needs to call — those belong in modules and scripts. The condition that flips the answer is whether the analysis is settled: while you are figuring it out, notebook; once you know, script.

When NOT to use this Never trust a notebook result you have not reproduced with Restart Kernel and Run All. Out-of-order execution means the numbers on screen can come from a variable defined in a cell you have since edited or deleted, and this failure is invisible — the notebook looks complete and coherent. Do the restart-and-run before every share, every submission, and every claim you make from a notebook. And clear outputs before committing or sharing: .ipynb files store results inline, including data extracts you may not intend to publish.

Common questions

Is Jupyter free?

Yes — free and open source under a BSD licence, maintained by Project Jupyter under NumFOCUS. There is no paid tier. Hosted services built on it, such as Google Colab, have their own pricing.

Why is version control hard with Jupyter notebooks?

Because .ipynb files are JSON containing both code and stored outputs, so a one-line change produces an unreadable diff and re-running produces changes even when the code is identical. Jupytext solves this by pairing each notebook with a plain .py or .md file that Git can diff properly.

Jupyter or Quarto?

Quarto when the output is a document — a report, a paper, a website — because plain-text source diffs cleanly and renders to publication quality. Jupyter when the activity is exploration and the interleaved, immediate feedback loop is the point. Many people use both, at different stages of the same project.