IPYNB vs PDF: Why They're Not Interchangeable (and When to Use Each)

The .ipynb file and the PDF are both "Jupyter Notebook outputs," but they're built for completely different jobs. Confusing them leads to broken shares, lost outputs, and archived files that can't be read five years later.

This guide walks through what each format is actually good at, where they fail, and how to choose between them in practice.

What's in an IPYNB File, Really?

A .ipynb file is a JSON document containing:

• Cells (code, markdown, raw)
• Outputs from the last execution (images, tables, text, errors)
• Metadata (kernel info, language version)
• Execution count (the [1], [2] numbers next to cells)

Critically, the outputs are baked into the JSON at the time of last save. If you share a .ipynb, the recipient sees your outputs without re-running anything — if they have a way to view .ipynb files.

What's in a PDF?

A PDF is a fixed-layout document. Every glyph, image, and vector is positioned at an exact (x, y) coordinate on a fixed-size page. There's no "code" or "outputs" — just rendered marks on virtual paper.

This means:

• A PDF looks identical on every device and in every reader.
• A PDF is frozen at the moment of conversion. Re-running the original notebook doesn't change it.
• A PDF cannot be edited back into a notebook (despite various tools claiming otherwise — the round-trip is always lossy).

Where IPYNB Wins

1. Iterative Analysis

If you're still exploring data, testing hypotheses, or tuning a model, .ipynb is the right format. You can re-run cells, tweak parameters, and see results immediately. A PDF is a snapshot — useless for iteration.

2. Reproducible Research

When you publish a notebook alongside a paper, the .ipynb lets readers reproduce your work, change inputs, and verify results. A PDF can't be re-executed.

3. Version Control (with Care)

.ipynb files diff reasonably well in Git, especially with tools like ReviewNB or nbdime. PDFs are binary blobs that produce useless diffs.

4. Embedding Rich Outputs

.ipynb supports interactive widgets (plotly, ipywidgets, altair), JavaScript-based outputs, and even embedded HTML. PDF supports none of these.

5. Editing After the Fact

Need to fix a typo in cell 47? Easy in .ipynb. In a PDF, you're either regenerating from source or paying for Acrobat.

Where PDF Wins

1. Universal Viewing

PDF is the closest thing the computing world has to a universal document format. Every laptop, phone, tablet, and e-reader can open one. .ipynb requires either Jupyter, GitHub's notebook viewer, or a specialized tool like nbviewer.

2. Archival Stability

A PDF from 2010 opens identically today. A .ipynb from 2010 may depend on a Python 2 kernel, packages that no longer exist, and outputs that reference missing files. For long-term archival, PDF is dramatically more reliable.

3. Print and Sharing

If you need to:

• Email a report to a non-technical stakeholder
• Submit homework to a learning management system
• Print a document for a meeting
• Upload to a system that only accepts PDF (most government and academic portals)

...PDF is the only realistic choice.

4. Fixed Layout for Compliance

In regulated industries (finance, pharma, healthcare), you often need a fixed, tamper-evident record of an analysis at a specific point in time. PDFs can be signed, timestamped, and audited in ways that .ipynb files cannot.

5. Smaller File Size (Sometimes)

A notebook with embedded base64 images can balloon to 50+ MB. The same content as a PDF is often 5–10× smaller, because PDF uses efficient image compression and doesn't carry the JSON overhead.

The Failure Modes

IPYNB Failure: "It works on my machine"

You send a .ipynb to a colleague. They open it in Jupyter and see:

• Missing outputs (their kernel re-ran and your outputs were discarded)
• Broken images (you referenced local files)
• Different versions of packages producing different results

A PDF avoids all of these by being a fixed snapshot.

PDF Failure: "I need to change one number"

You convert a notebook to PDF for a report. Two days later, you realize cell 23 has a bug. The PDF is useless — you have to fix the notebook and re-export. There's no such thing as "editing a PDF notebook."

This is actually fine if you keep the source .ipynb alongside the PDF. The PDF is the output; the notebook is the source.

The Right Workflow: Keep Both

The professional workflow is:

1. Develop in .ipynb — iterate, explore, get the analysis right.
2. Save the .ipynb as the canonical source — commit it to Git.
3. Export to PDF for sharing — use this for reports, emails, submissions.
4. Re-export when the notebook changes — treat the PDF as a build artifact.

This workflow treats the PDF like compiled software and the notebook like source code. Each has its role; neither replaces the other.

Format Comparison Table

When to Convert

Convert .ipynb to PDF when:

• Sharing with a non-technical audience
• Submitting to an academic or government system
• Archiving an analysis for compliance
• Emailing a report
• Printing

Keep .ipynb (don't convert) when:

• Iterating on the analysis
• Collaborating with other developers
• Publishing reproducible research
• Version-controlling the work

Conclusion

IPYNB and PDF aren't competitors — they're complements. The notebook is your source code and reproducibility artifact; the PDF is your sharing and archival format. Keeping both, and converting at the right moments, gives you the best of both worlds. The worst thing you can do is pick one format and use it for everything.