Why do ipywidgets disappear from an exported notebook?

A widget is a view onto a Python object living in the kernel. `nbconvert` produces a static file with no kernel, so anything whose value is computed on interaction has nothing to talk to. Only the serialized widget state saved with the notebook can be replayed.

How do you keep widget state in an nbconvert export?

Save the notebook with widget state — in Jupyter, Widgets → Save Notebook Widget State, or `jupyter nbconvert --to html --no-input notebook.ipynb` after saving state. That reproduces the widgets' last rendered values, not live interaction.

What is the difference between nbconvert and Voilà here?

`nbconvert` produces a document. Voilà runs a kernel behind the page, so widgets stay live — at the cost of hosting a server per session. Choose by whether readers need to change inputs or only read conclusions.

Do Plotly and Altair charts survive nbconvert?

Yes, because they render to self-contained JavaScript rather than talking to the kernel — provided the library is embedded. Plotly needs `include_plotlyjs=True`, Altair needs `inline=True`, or the export references a CDN that may be blocked.

What is the simplest way to share the exported notebook?

Publish the HTML export and send the URL. It keeps the charts interactive inside a sandboxed frame, drops the `file://` failures, and lets readers comment on a specific cell's output instead of screenshotting it.

The widgets are gone from the export

The notebook is perfect in the browser. jupyter nbconvert --to html produces a file where the sliders are missing, the dropdown is a blank space, and the cell below it shows the output from whatever value happened to be selected last — or nothing at all.

The reason, in one sentence

An ipywidgets widget is a view onto a Python object living in the kernel. The export has no kernel. There is nothing on the other end of the slider.

This is not a bug and no flag fixes it in general, because "make this static file recompute a Python callback" is not a thing a static file can do.

What you can actually keep

Serialized widget state. Jupyter can embed the widgets' last state into the notebook, and nbconvert will then render them:

In Jupyter Notebook: Widgets → Save Notebook Widget State, save, then convert.
In JupyterLab: the same option under the settings for the notebook, or set store_widget_state in the config.

The result is widgets that appear, with their last values, and do not respond to interaction. For a report showing "here is the analysis at these parameters", that is often exactly enough.

Everything that renders to plain JavaScript. Plotly, Altair, Bokeh, ECharts and friends do not need the kernel — they serialize the data and the rendering code into the page. They survive the export intact, as long as the library itself is embedded rather than pulled from a CDN that might be blocked:

fig.write_html(..., include_plotlyjs=True)   # Plotly
chart.save("chart.html", inline=True)        # Altair

If those come out blank, the cause is the library, not the kernel — see Plotly chart missing from the exported HTML.

Images. --embed-images inlines matplotlib output as data URIs so the export is one self-contained file instead of an HTML plus a notebook_files/ directory that gets separated from it:

jupyter nbconvert --to html --embed-images analysis.ipynb

That single flag prevents the most common "my exported notebook lost all its plots" report, which is really an entry file that travelled without its folder.

When you genuinely need live widgets

Then you need a kernel, which means a server:

Voilà renders the notebook as an app with a live kernel behind it. Real interactivity, real hosting — one process per viewer session, and an authentication story you have to build.
Panel, Streamlit, Gradio, Shiny — same trade in different clothes.

Worth being honest about the choice: most notebook "reports" are read once by three people who want the conclusion. Paying for a live kernel per reader to preserve a slider that nobody moves is a bad trade. Export at the parameters that matter, and if the reader wants different parameters, they will ask — which is a conversation, not a server.

Sharing the export

Once you have HTML, the remaining problem is delivery. file:// copies break XHR-loading outputs, email clients strip scripts (why), and a 30 MB self-contained notebook is awkward as an attachment.

Publish it and send a link. The charts stay interactive — scripts run in a sandboxed iframe (allow-scripts, no allow-same-origin) — and the reader can select the cell output they have a question about and ask it there, anchored to that output, instead of quoting it into Slack (comment on HTML).

Re-running weekly? A routine can execute the notebook on a cron and post the refreshed export as a new revision at the same URL, so the link in the team doc is always current.

Limits: entry HTML 5 MB; assets 25 MB per file, 250 MB and 500 files per report.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a notebook export →