Jupyter Notebook (.ipynb) Viewer
Open a Jupyter notebook (.ipynb) and read it the way it was meant to be read: Markdown cells rendered as formatted prose, code cells shown with their execution numbers, and outputs displayed inline — text results, plots and images, stream output, and error tracebacks with the ANSI colour codes cleaned up. There is no kernel and nothing is executed; the notebook's saved JSON is simply rendered. It all happens in your browser, so a notebook full of unpublished analysis stays on your machine.
How to use the Jupyter Notebook (.ipynb) Viewer
Paste the contents of an .ipynb file into the box or load the file directly. An .ipynb is just JSON, so you can open it in any text editor, copy it, and drop it here. The viewer reads the cells array and renders each cell in order. It understands the current notebook format (nbformat 4), and it also handles the older nbformat 3 layout where cells were nested inside worksheets.
Markdown cells are rendered with a built-in formatter that handles headings, bold and italic, inline code and fenced code blocks, blockquotes, ordered and unordered lists, links, images, and horizontal rules — enough to read the narrative of a notebook cleanly. Code cells show their source in a monospaced block with an In [n]: prompt reflecting the execution count, followed by any saved outputs. Stream output (what print wrote) appears as plain text, with standard error tinted red. Execution results and display data show inline: a saved PNG, JPEG, or SVG image is rendered, and a text result is shown as-is. Error outputs display the traceback with Jupyter's ANSI colour codes stripped so it reads as clean text.
The status line reports the notebook's shape: how many cells, the split between markdown, code, and raw cells, the kernel language, and the nbformat version. Because nothing is executed, the outputs you see are exactly those that were saved in the file when it was last run — which is precisely what you want when reviewing someone else's notebook or checking what a committed notebook actually contains. To keep things safe, the renderer escapes all content and never runs scripts, and it shows the plain-text form of rich outputs rather than executing any embedded HTML.
What an .ipynb file is
A Jupyter notebook is a document that interleaves runnable code, its output, and explanatory prose. It grew out of the IPython project and became the standard medium for data science, scientific computing, and teaching, because it lets you build an analysis and its narrative together: a paragraph of Markdown, the code that backs it up, and the chart that code produced, all in one scrollable document. The file on disk has the extension .ipynb, short for "interactive Python notebook", though notebooks today run dozens of languages through different kernels.
Despite the rich interface, an .ipynb file is plain JSON. At the top level it has a cells array, a metadata object, and nbformat version numbers. Each cell has a cell_type — markdown, code, or raw — and a source field that is usually stored as an array of line strings rather than one big string, a quirk that makes diffs cleaner but surprises people opening the file for the first time. Code cells additionally carry an execution_count and an outputs array. Each output is itself an object tagged with an output_type: stream for console text, execute_result and display_data for returned values and rich media, and error for exceptions, with the traceback stored as an array of strings.
The detail that makes notebooks awkward in version control is that outputs are saved inside the file. A committed notebook can carry megabytes of base64-encoded images and a full traceback from the last time it ran, which is why teams often strip outputs before committing and why a notebook diff can be unreadable. The metadata records the kernel and language so a viewer knows how to label things, but it has no bearing on what is displayed: the outputs are frozen snapshots, not live results. That is the key thing to understand when reading a notebook you did not run — what you see is a recording. A viewer that renders the saved JSON faithfully, without a kernel, lets you read that recording quickly and safely, whether you are reviewing a pull request, grading an assignment, or just checking what a file contains before opening a heavyweight environment.
Common use cases
- Reviewing a notebook in a pull request. Read the rendered cells and saved outputs without spinning up Jupyter.
- Checking committed outputs. See whether a notebook was committed with heavy image outputs or a stale traceback still inside it.
- Reading shared analysis. Open a colleague's notebook to follow the narrative and results before deciding to run it.
- Grading or teaching. Skim student submissions quickly, seeing both the code and what it produced.