Project Jupyter

Project Jupyter provides a common environment for writing, running, and communicating computational work. Its central document, the notebook, is a structured file containing code cells, Markdown text, equations, media, and saved outputs; the format is designed to preserve both the procedure and the explanation of an analysis.¹

The project grew from IPython, an interactive Python shell created by Fernando Pérez and colleagues. In 2014, IPython’s language-independent components became Project Jupyter, while IPython continued as a Python kernel and interactive shell. The name refers to Julia, Python, and R, the first three languages emphasized by the project.² Jupyter is therefore not a programming language or a single application, but a collection of interoperating standards, tools, and communities.

Jupyter separates the user interface from the program that executes code. A notebook client communicates with a language-specific kernel through the Jupyter messaging protocol; the kernel runs code, maintains state, and returns results such as text, images, or errors.³

JupyterLab is the project’s extensible web-based environment for notebooks, terminals, text editors, consoles, and data viewers, while the classic Notebook interface remains a widely used client.⁴ The nbformat specification stores notebooks as JSON, making them portable and suitable for version control, although rendered outputs and execution order can create review and reproducibility problems. Kernels exist for many languages beyond the name’s original trio, including Bash, Java, MATLAB, Ruby, and Scala, through community-maintained implementations.

Jupyter is used for exploratory data analysis, scientific computing, teaching, demonstrations, and reproducible communication. A notebook can place a statistical argument, its source data transformations, executable code, and charts in one readable artifact; researchers also use notebooks to document simulations and produce figures for publications.¹

Interactive execution is not identical to a fully reproducible experiment. Cells can be run out of order, depend on hidden state, or rely on packages and files absent from another computer. Reproducibility therefore benefits from explicit environment specifications, controlled data access, recorded versions, and automated execution or testing. Jupyter supports these practices but does not enforce them. Security is another boundary: notebooks may contain executable code, and opening an untrusted notebook can expose a user to malicious behavior; trusted-notebook mechanisms and cautious review are consequently part of responsible deployment.

Jupyter’s ecosystem extends well beyond the familiar notebook interface. JupyterHub provisions multi-user Jupyter environments, making the project useful in universities, classrooms, and shared research infrastructure; Voilà can turn notebooks into standalone interactive applications; and Binder enables temporary, shareable computing environments built from a repository’s declared dependencies.⁴

The notebook format is also used as a document interchange layer: tools can convert notebooks into HTML, PDF, presentations, and other formats, while kernels allow one interface to address different computational languages. Project governance is community-based and supported by institutional and individual contributors, with legal and fiscal support from NumFOCUS.⁵ A notable design choice is that Jupyter emphasizes protocols and reusable components rather than requiring every user to adopt one desktop application.

Notebook

A structured document combining executable cells, prose, metadata, and saved computational outputs.

Kernel

A process that executes code for a particular programming language and communicates with a Jupyter client.

JupyterLab

An extensible web-based Jupyter client integrating notebooks with consoles, terminals, editors, and data tools.

nbformat

The JSON-based file format and specification used to represent Jupyter notebooks.