Data work on web and software projects usually ends up in a Jupyter notebook. The analytics review, the A/B test readout, the performance audit, the churn model: the analyst runs it cell by cell, writes notes in between, and the notebook becomes the record of what was found. Then someone asks to send it to the client, and the problem starts. The client does not have Jupyter, does not want a GitHub account, and should not have to read 300 lines of pandas to find the one chart that matters.

Here is a handoff process that development and data teams can repeat on every project, so the client receives something they can open, read and forward in a minute.

Why the .ipynb file itself is the wrong deliverable

An .ipynb file is JSON. It holds the code, the markdown, and the output each cell produced the last time it ran. Opened in a text editor it is unreadable; opened in Jupyter it needs a Python environment. Even when a client manages to view it on GitHub or in a preview tool, three problems remain:

• Stale outputs. If cells were run out of order or edited after running, the charts may not match the code beside them.
• Noise. Import blocks, debugging prints and half-finished experiments sit between the findings.
• No fixed version. A notebook keeps changing. A client needs a snapshot they can cite in a meeting next month.

A PDF solves all three. It opens on any phone or laptop, it prints cleanly, and it freezes the analysis exactly as it was on the day you sent it.

Step 1: Restart the kernel and run everything

Before exporting, use Kernel, Restart and Run All, then save. This proves the notebook runs top to bottom and that every output matches the code that produced it. If a cell fails here, it would have failed for anyone trying to reproduce your numbers, so fix it now rather than after the client asks why a figure changed.

Step 2: Decide who the reader is

Most projects have two audiences. A product owner or executive wants the conclusion, the chart and a sentence of explanation. A technical reviewer on the client side wants to see the method. Make two versions if you have both readers:

• Report version: markdown, tables and charts only, with the code cells hidden.
• Technical version: everything included, with In and Out numbers so a reviewer can follow the order of execution.

Step 3: Edit the notebook like a document

A notebook that reads well as a PDF is mostly a writing job, not a coding one.

• Put a short summary in the first markdown cell: what was asked, what you found, and what you recommend.
• Give every chart a title, labelled axes and units. A reader of the PDF cannot hover over a point to see its value.
• Write one sentence under each chart saying what it shows. "Conversion dropped 12% after the checkout redesign" is more useful than the chart alone.
• Delete exploratory cells that went nowhere, or move them to a separate scratch notebook.
• Limit wide DataFrames to the columns that matter. Twenty columns will not fit on a page.
• Replace interactive Plotly or Bokeh charts with static images for the export. Interactive output needs JavaScript and will not appear in a PDF.

Step 4: Export to PDF

Jupyter ships with nbconvert, which can export from the command line. jupyter nbconvert --to pdf report.ipynb produces a PDF through LaTeX, so it needs a full TeX installation and often stops with an "xelatex not found" error on machines that do not have one. jupyter nbconvert --to webpdf report.ipynb renders through a headless Chromium browser instead, and adding --no-input hides the code cells for the report version.

That works well on a developer's own machine. It is less convenient for a project manager on a locked-down company laptop, or for anyone working from Google Colab or Kaggle. In those cases a browser tool is faster: you can convert a Jupyter notebook to PDF by uploading the .ipynb file, choosing whether to keep or hide the code, and downloading the result, with no LaTeX or Python setup. From Colab, download the notebook first with File, Download, Download .ipynb.

Step 5: Check the PDF before it goes out

Open the file and scroll through every page before you attach it. Look for:

• Charts split across a page break or shrunk too small to read.
• Code lines that run off the edge of the page in the technical version.
• Error tracebacks left in the output.
• Math in markdown cells that appears as raw LaTeX instead of formulas.
• Any credentials, API keys or internal file paths printed in an output cell. These are easy to miss and awkward to retract.

Step 6: Name and store it like a deliverable

Use a file name the client can sort and search, such as 2026-10-15_checkout-ab-test_report.pdf. Keep the .ipynb in your repository as the source of truth and treat each PDF as a dated snapshot. When the client comes back with a question three months later, you can open the exact version they saw rather than the notebook as it is today.

A repeatable handoff

None of these steps takes long, and together they change how the work is received. The client gets a document instead of a file they cannot open, the findings are at the top instead of buried in code, and your team has a dated record of what was delivered. For agencies and freelancers who bill for analysis, that difference shows up in how quickly the client acts on the results.