What each notebook export keeps and drops

Converting a notebook is not “saving as.” Each target format has a different idea of what a document is, so each export keeps a different slice of the .ipynb JSON and drops the rest. If you pick the format by file extension alone, you will eventually hand someone a file that is missing the part they needed: the plot, the prose, the runnable code, or the ability to comment.

This guide compares the formats people actually ask for. It assumes the input is a normal nbformat notebook, the same shape described in what an .ipynb file contains. The public sample notebook is small enough to convert in every direction that accepts .ipynb and then open the result. Where a format cannot represent something, that is a property of the format, not a glitch in one button.

None of these exports re-run Python. They read cells and outputs that are already stored. If a chart was never saved into the notebook, no PDF, Word file, or HTML page can reconstruct it.

A comparison you can check

Read each row as: what happens to that piece in PDF, Word, Markdown, HTML, and Python, in that order.

• Markdown headings and lists. Formatted text in PDF. Word styles where the converter maps them. Still Markdown. HTML headings and lists. Usually comments in a Python file.
• Code source. Monospace text in PDF. A code block or styled paragraph in Word. A fenced block in Markdown. A code element in HTML. Real Python in a script.
• Saved text outputs. Kept in PDF, Word, Markdown, and HTML when the tool is asked to include outputs. Omitted from Python by default so the file stays a script.
• Saved plot images. Embedded in PDF, Word, and HTML when they are already in the notebook. Markdown has to point at extracted files or inline them. A Python script does not include them.
• Kernel name and package list. None of these formats is a runnable environment. The name in notebook metadata does not install packages.
• Re-running cells. PDF, Word, Markdown, and HTML do not run code. A Python file runs only if you execute the script yourself, and only in source order.
• Editing prose and leaving comments. PDF is a poor place to edit. Word is built for comments. Markdown is built for Git. HTML is awkward. A Python file is a poor place for prose comments beyond short notes.
• Fixed pages. Only PDF is a fixed page layout. Word re-flows when someone edits it. Markdown, HTML, and Python have no pages.

ODT follows the Word column more than the PDF column: it is an editable document, not a frozen page. LaTeX keeps structure as TeX source you still have to compile. JPG and slides are snapshots or presentations, not archives of the notebook. Those are called out below because they are easy to mistake for a full export.

PDF

A PDF is a paginated, fixed-layout copy. Headings, paragraphs, code, and saved figures can all appear, in the order of the cells. Page size, margins, and font choices affect wrapping. Long lines of code may break or shrink. That is normal for PDF and is not a sign that the source cell was truncated in the notebook itself.

What PDF does not do:

• It does not keep a notebook. You cannot open a PDF in Jupyter and get the cells back.
• It does not re-execute code, refresh numbers, or fix an output that was stale when you exported.
• It does not include your conda environment, your data files, or widgets that only existed as a live frontend.
• Math may be approximated. A notebook full of LaTeX delimiters can look right in Jupyter and merely acceptable in PDF, depending on the converter. If a journal requires real TeX, export LaTeX and compile it, or use a local nbconvert setup with a TeX install.

Use PDF when the reader must see a stable layout: a course portal, a printed packet, an email to someone who will not install Jupyter. Do not use PDF as the only copy if you still need to edit the analysis.

Word and ODT

Word (.docx) and OpenDocument Text (.odt) are editable documents. Markdown becomes paragraphs and headings. Code becomes monospace text. Saved images can be embedded. Someone can leave comments in Word, which is the actual reason many teams ask for it.

What they do not do:

• They are not round-trip notebook formats. Turning the document back into .ipynb is a guess about which paragraphs were code. A later Word-to-notebook pass will not restore outputs, cell ids, or execution counts.
• They re-flow. A heading that sat at the top of a PDF page may sit in the middle of a Word page after someone edits a paragraph.
• Tracked changes and comments live in the document format, not in the original notebook. If you need those comments preserved, keep the .docx. The .ipynb does not gain them automatically.

Choose Word or ODT when a person will edit prose or review in a familiar editor. Choose PDF when they must not be able to shift the layout by accident.

Markdown

Markdown keeps the narrative and, if you ask for it, fenced code blocks and textual outputs. It is the format that belongs in a Git repository next to the notebook when you want a readable diff. Images are the awkward part: a Markdown file is text, so figures have to be referenced as files or inlined in a way the destination understands. A converter may write image files beside the .md or embed them. If you only download the .md and not the images, the pictures disappear. That is expected.

Markdown does not have pages, headers, or page numbers. It does not keep Word comments. It does not run. It is a good archival companion to the .ipynb, not a replacement for the notebook if you still need outputs regenerated.

HTML

HTML is a single page you can open in a browser, often with the styling baked in so the file stands alone. Code can be highlighted. Saved HTML outputs from the notebook sometimes drop in more faithfully than they do in PDF, because the notebook already stored HTML. Scripts and widgets in those outputs are a security and fidelity problem: a static export should not become an unexpected web app. Treat interactive output as “maybe a snapshot, maybe omitted,” and check the result.

HTML is not a notebook. It is not paged for print. Browser print-to-PDF is a third format, with its own page breaks, and it is not the same as a dedicated PDF export.

Python

A .py export takes code-cell source and, depending on options, turns Markdown into comments. Outputs are usually dropped on purpose so the file is a script rather than a transcript. Execution counts, figures, and HTML tables do not belong in a Python file.

The script is not guaranteed to run top to bottom even if every cell ran in the notebook. Notebooks allow cells to run out of order and to rely on state from cells you later deleted. A linear script preserves source order, not the historical order of Shift+Enter. If the notebook imported packages, the script still needs those packages installed. The notebook metadata does not install them.

The reverse direction, a Python file turned into a notebook, splits the script into cells by heuristics (blank lines, comments, or markers). It cannot recover outputs that the .py file never had.

Formats that are intentionally lossy

JSON. Pretty-printed notebook JSON is the notebook. It keeps cells, outputs, and metadata. It does not make the file easier for a non-programmer to read. Use it when you need to inspect or archive the structure, not when you need a report.

LaTeX. You get .tex source. Figures may be extracted or referenced. You still compile. Errors from missing packages or fragile Unicode are TeX errors, not notebook errors.

JPG. A JPEG is a picture of content, often one tall image or a set of images. It has no selectable code semantics, no reflow, and no accessible heading structure worth relying on. Text in the image can be blurry at small sizes. Use it for a thumbnail or a chat preview, and keep the notebook or a PDF for anything someone must read carefully.

EPUB. An ebook can carry the prose, code, and images in reading order. E-readers differ on code wrapping and on math. It is not a print master and not a notebook.

Slides. A slideshow uses slide breaks, or one cell per slide, depending on the tool. Speaker notes, hidden cells, and dense outputs often fit badly. A slide deck is a presentation cut of the notebook, not a backup.

ZIP. A zip bundles files. It does not convert anything by itself. Whatever you put in the archive is what the other person gets. If the archive includes only the notebook, they still need a way to open .ipynb.

requirements.txt extraction. This lists imports it can see in code source. It misses packages that are imported under a different name, packages used only in a shell command, version pins, and anything installed but not imported. It will not recreate an environment.

How to choose

Ask what the reader will do with the file tomorrow.

• They will read a frozen copy and should not edit it: PDF.
• They will edit prose or comment: Word or ODT, and keep the .ipynb as the source of the analysis.
• They will diff in Git: Markdown and the notebook, with outputs stripped if the diff is about code.
• They will run the code as a script: Python, after you accept that cell order and hidden state may not match the notebook session.
• They only need to look, once, on a phone: a viewer or HTML, not a JPEG of the whole notebook.

Then check the result against the sample notebook or against your own file before you send it. Confirm whether saved output was supposed to be included. Confirm that figures you see on your laptop are actually stored in the .ipynb and not only on screen. The walkthrough of the sample notebook does that check in public, format by format, so you can see a small honest result instead of a promise.