Online Tool Store
· 4 min read
How to Open an .ipynb File Without Jupyter
Manesh Jayawardhana
CIO & Co-founder
Someone emails you an analysis as a .ipynb file. You don’t have Python installed, you’re not going to install it to read one document, and opening the file in a text editor gives you JSON with base64-encoded images in it.
The notebook already contains everything you need to read it. It just needs rendering.
What’s inside an .ipynb file
It’s JSON. An array of cells, each either markdown or code, and each code cell carrying:
- its source, the code as written
- its outputs, saved from the last time it ran
- its execution count, the number shown as
In [7]
That third field is the interesting one, and it’s the reason viewing a notebook is more informative than it first appears.
Execution counts tell you whether to trust it
The execution count records the order cells were actually run. In a notebook run cleanly from top to bottom, they read 1, 2, 3, 4 down the page.
In a real working notebook they often read something like 1, 5, 2, 9, 3 — because the author ran a cell, went back, changed something above, ran that, came back down. Perfectly normal while working.
The problem is what it means for the reader. Non-sequential counts mean the saved outputs were produced by a sequence of operations that doesn’t match reading the notebook top to bottom. Run it fresh and you may get different results, because some cell depended on state created by a cell that has since been edited.
This is the well-known hazard of sharing notebooks: the outputs are a record of one past session, not a guarantee about the code as it now stands. A cell whose code was edited after it ran displays output that no longer corresponds to what’s above it.
So the first thing to check on any shared notebook isn’t the conclusion — it’s whether the execution counts run in order.
| Execution counts | Means |
|---|---|
| 1, 2, 3, 4… in order | Run cleanly top to bottom — outputs match |
| Non-sequential | Run out of order — outputs may not reproduce |
| Some cells blank | Never run in this session |
| Gaps in the sequence | Cells were deleted after running |
Why people get stuck here
- No Python. Installing an interpreter to read a document is disproportionate.
- Raw JSON is unreadable. Outputs are base64 blobs and source is an array of strings with escaped newlines.
- Hosted viewers require upload. Which is a problem when the notebook contains company data.
- Outputs look authoritative. A chart in a notebook reads as current even when the code above it changed afterwards.
Common mistakes to avoid
- Trusting an output without checking whether the cell producing it ran after the code was last edited.
- Uploading a notebook containing internal data to a hosted rendering service.
- Assuming a notebook that produced a result will produce it again — hidden state from a long session is common.
- Reading conclusions from the markdown without checking that the code supports them.
- Sharing a notebook without restarting the kernel and running it top to bottom first, which is the courtesy that makes it reproducible.
How to do it with Jupyter Notebook Viewer
The Jupyter Notebook Viewer renders the notebook in your browser, with the file staying on your device.
- Open the
.ipynbfile — it’s read locally, not uploaded. - Read the cells and their saved outputs.
- Check the execution counts before trusting any result.
- If the counts are out of order, treat the outputs as indicative and ask for a clean run.
Jupyter’s notebook format documentation describes the JSON structure if you need to process it programmatically. Other developer tools are in the tools directory.
Frequently asked questions
Can I run the code here?
No. This displays the notebook and its stored outputs. Running cells requires a Python kernel — Jupyter, a hosted runtime, or a local environment.
Why do execution counts matter?
They reveal the order cells were actually run. Counts of 1, 5, 2, 9 mean the notebook was executed out of order, and its stored outputs may not reproduce from a clean run.
Are notebook outputs trustworthy?
They’re a record of one past run. If the code changed after that run, the output no longer matches the code above it — a well-known hazard of sharing notebooks.
Final thought
Check the execution counts first. They take two seconds to read and they tell you whether the rest of the notebook means what it appears to.