Getting Started with Jupyter Notebook (formerly IPython Notebook)

Blog / Python · September 10, 2021 · Updated June 10, 2026 · 7 min read
Getting Started with Jupyter Notebook (formerly IPython Notebook)

If you searched for the IPython Notebook, you have found the right tool under its current name: Jupyter Notebook. The project was renamed Jupyter in 2014 when its language-agnostic parts split out from IPython. The original IPython project lives on as the Python kernel that Jupyter runs by default, so a Python notebook today is still powered by IPython under the hood — you just install and launch it as Jupyter.

Jupyter lets you write and run Python code in interactive cells, mix it with Markdown notes, plots, tables and images, and share the result as a single document. It is the default workspace for data analysis, machine learning, teaching and quick prototyping. This 2026 guide covers how to install it, where people run notebooks now, the core concepts, and the practices that keep notebooks maintainable.

Install and run Jupyter in 2026

Always install Jupyter inside a virtual environment so its dependencies stay isolated from your system Python and from other projects. The two packages you want are jupyterlab (the modern interface) and notebook (the classic single-document interface, now version 7):

# create and activate a virtual environment
python3 -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate

# install Jupyter into the venv
pip install jupyterlab notebook

Prefer a faster, modern toolchain? uv works the same way (uv venv then uv pip install jupyterlab notebook), and the Anaconda / conda distribution ships Jupyter pre-installed if you work in that ecosystem.

To launch, run one of these from your project directory. Jupyter starts a local server and opens your browser at http://localhost:8888:

jupyter lab          # modern, IDE-like interface (recommended)
jupyter notebook     # classic single-document interface (Notebook 7)

JupyterLab vs the classic Notebook

JupyterLab is the primary, IDE-like interface: a file browser, multiple notebooks and terminals in tabs, a built-in debugger, and an extension ecosystem. Notebook 7 is the lighter single-document experience — and importantly it is now rebuilt on the same JupyterLab components under the hood, so the two share rendering and behaviour. Use JupyterLab for real work, and reach for jupyter notebook when you want a focused, single-file view. The notebook file format (.ipynb) is identical in both.

Where people run notebooks in 2026

You are no longer limited to a local browser tab. The same .ipynb file opens in several environments, each suited to a different job:

Environment Best for Runs where Notes
JupyterLab Local, full-control data work Your machine Free, extensible, offline; you manage the Python env
VS Code notebooks Developers who live in an editor Local / remote / containers Opens .ipynb natively; strong Git and debugging
Google Colab Quick experiments, free GPUs Hosted by Google Zero setup, shareable; free GPU/TPU tiers
JupyterHub Teams, classrooms, shared servers Self-hosted / cloud One Jupyter per user with central auth
Cloud studios Production ML pipelines AWS SageMaker Studio and similar Managed notebooks next to cloud data and training

A common workflow is to prototype in Colab or JupyterLab, then move the same notebook into VS Code or a cloud studio as the project matures.

Core concepts: cells, kernels, and the .ipynb format

A notebook is an ordered list of cells. Each cell is either code (executed by the kernel) or Markdown (rendered as formatted text — headings, lists, math, images). Run the focused cell with Shift+Enter; its output appears directly beneath it.

The kernel is the process that actually runs your code and holds your variables in memory. When state gets confusing, use Kernel -> Restart & Run All to execute every cell from a clean slate — this is the single most useful habit in notebook work. While the default kernel is Python (provided by IPython), Jupyter is language-agnostic: kernels exist for R, Julia, Scala, Bash and dozens more.

Notebooks are saved as .ipynb files. Despite the extension, an .ipynb is simply a JSON document that stores your cells, their outputs and metadata. To reuse one, drop it into your working directory and open it from the file browser.

Magics and rich output

Magic commands are IPython shortcuts that are not part of Python itself. Line magics start with % and operate on one line; cell magics start with %% and operate on the whole cell. They cover timing, profiling, shell access, loading code and more:

%timeit sum(range(1000))         # time a one-line statement
%matplotlib inline               # render Matplotlib charts in the notebook

%load_ext autoreload             # auto-reimport edited modules
%autoreload 2

%load analysis.py                # pull an existing .py file into the cell
%run analysis.py                 # execute a .py file and show its output

%%bash
echo "cell magics run the whole cell — here, as a shell script"

Exporting notebooks with nbconvert

nbconvert turns a notebook into other formats for sharing or automation — HTML to send to a colleague, PDF for a report, or a plain .py script to fold back into a codebase. It ships with Jupyter:

jupyter nbconvert --to html analysis.ipynb     # shareable HTML
jupyter nbconvert --to pdf analysis.ipynb      # PDF report (needs LaTeX)
jupyter nbconvert --to script analysis.ipynb   # extract a .py script

# run a notebook end-to-end as part of a pipeline
jupyter nbconvert --to notebook --execute analysis.ipynb

Good practices and honest caveats

Notebooks are excellent for exploration but have real failure modes worth knowing:

  • Out-of-order execution and hidden state. Because you can run cells in any order, a notebook can appear to "work" only because of variables left over from cells you have since changed or deleted. Before you trust a result, run Restart & Run All from top to bottom.
  • Version control is awkward. An .ipynb is JSON with embedded outputs, so it diffs poorly in plain Git. Clear outputs before committing, use nbdime (nbdiff / nbmerge) for notebook-aware diffs, or use jupytext to pair each notebook with a clean .py file that Git can read normally.
  • Reproducibility. Pin your dependencies (a requirements.txt or lockfile in the same repo) so the notebook runs the same way next month and on someone else's machine.
  • Graduate code out of the notebook. Once a function is stable and reused, move it into a .py module and import it back into the notebook. Notebooks are for exploring; production logic belongs in tested modules and packages.
  • Security. A notebook can run arbitrary code, so only open .ipynb files from sources you trust — treat an unknown notebook like an unknown script.

These same habits underpin how we build data and AI features for clients: explore in a notebook, then harden the proven parts into maintainable Python.

Want to go deeper into the language itself? See why Python is a strong backend choice, get hands-on with Python collections, try web scraping with Beautiful Soup, or generate Excel reports and charts with XlsxWriter — all natural next steps from a notebook.

At MicroPyramid we have spent 12+ years and 50+ delivered projects building Python data and AI systems, much of which started life in exactly these notebooks before becoming production services.

Frequently Asked Questions

Is IPython Notebook the same as Jupyter?

Yes. The tool once called the "IPython Notebook" was renamed Jupyter Notebook in 2014, when the language-agnostic parts split out into the Jupyter project. The original IPython lives on as Jupyter's default Python kernel, so when you run a Python notebook today you are still using IPython under the hood — you just install and launch it as jupyter.

Should I use JupyterLab or Jupyter Notebook?

Use JupyterLab for most work: it is the modern, IDE-like interface with tabs, a file browser, a debugger and extensions. Reach for the classic Notebook 7 (jupyter notebook) when you want a single, focused document view. Notebook 7 is now built on the same components as JupyterLab, and both use the identical .ipynb format, so you can switch freely.

Jupyter, VS Code, or Google Colab — which should I pick?

All three open the same .ipynb file. Choose JupyterLab for full local control of your environment, VS Code if you already work in that editor and want strong Git and debugging, and Google Colab for zero-setup experiments and free hosted GPUs. Many teams prototype in Colab and move the notebook into VS Code or a cloud studio as it matures.

How do I version-control a Jupyter notebook?

Because .ipynb files are JSON with embedded outputs, they diff badly in plain Git. Clear cell outputs before committing, use nbdime for notebook-aware diffs and merges, or pair each notebook with a plain .py file using jupytext so Git tracks readable source. Commit a requirements.txt or lockfile alongside it for reproducibility.

How do I convert a notebook to a script or PDF?

Use nbconvert, which ships with Jupyter. Run jupyter nbconvert --to script notebook.ipynb for a .py file, --to html for a shareable page, or --to pdf for a report (PDF needs a LaTeX install). You can also execute a notebook headlessly with --to notebook --execute inside a pipeline.

Can Jupyter run languages other than Python?

Yes. Jupyter is language-agnostic: the name nods to Julia, Python and R. Python is the default via the IPython kernel, but you can install kernels for R, Julia, Scala, Bash, JavaScript and dozens of other languages and pick one per notebook.

Share this article