Converting without executing does not run the notebook's code cells, but saved outputs can contain HTML and JavaScript. Jupyter Server adds a sandbox to the Content-Security-Policy header for nbconvert pages by default, which confines that script. Executing during conversion is a different matter.
Two operations that sound alike
The nbconvert documentation describes converting and executing as separate things. Converting changes the format of a notebook file, for example to HTML. Executing runs the input cells and saves the results. The command that executes is the same tool with an execute flag added.
| Operation | Runs cell code | Risk to think about |
|---|---|---|
| Convert to HTML, no execute | No | Script inside saved outputs when a person views the page |
| Convert with execute | Yes | Everything the notebook code can do, as your account |
For the second row see the companion post on running notebooks in CI.
The sandbox default
The Jupyter security documentation explains the problem. Unlike other documents, a notebook includes output, and that output exists in a context that can execute code through JavaScript. When notebooks are rendered through the server's nbconvert endpoints, the server adds a sandbox allow-scripts directive to the Content-Security-Policy header by default. That confines any JavaScript in the rendered output to a unique origin, preventing it from interacting with the Jupyter server.
The setting is called nbconvert_csp_sandbox, and the documentation shows it as True by default:
c.ServerApp.nbconvert_csp_sandbox = True
The word allow-scripts means scripts may still run. They are isolated, not forbidden. They can still draw things on the page.
What to check on your setup
- Leave the sandbox setting at its default unless you have a reason and a compensating control.
- If you publish converted HTML on a website, serve it from a separate domain from anything with logins, so script in an output cannot reach your sessions.
- Never publish notebooks from untrusted authors without clearing outputs first.
- Remember the Jupyter trust model: HTML and JavaScript from outputs you did not generate are untrusted.
- Keep your Jupyter packages current. Security fixes for notebook rendering ship in releases, as with the 2026 advisory covered in /resources/blog/jupyterlab-cve-2026-102832-trust-prompt-wrong-document.
A safer publishing flow
For a public report from your own notebook:
- Run it in a clean environment you control.
- Review the saved outputs, especially any HTML or widget output.
- Convert to a static format.
- Serve the result from a static host on its own domain.
For a notebook from outside your team, read it as text first, and clear outputs before you convert it.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers the packages behind your notebook tooling, and the pull request gates can flag a vulnerable version before it merges. Try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how a gate decides before anything merges.
Quick check
Does the sandbox block all JavaScript in rendered notebooks?
No. The directive is allow-scripts, so scripts can run, but they are confined to a unique origin.
Does converting a notebook to HTML execute its code cells?
Not unless you also ask nbconvert to execute it.
Sources
- Security in the Jupyter Server, Jupyter documentation, fetched 19 October 2026.
- Executing notebooks, nbconvert documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
