Web export
Package a project as a self-contained website that opens in a browser with no install.
Web export packages the graph into a small folder you can host anywhere. There are two builds under the export panel's Web target: Full App (WebGPU), which runs the interactive piece live in the browser, and Audio Only, which ships just the sound.
See Exporting for the rest of the export picture.
Full App
The Full App build runs the real graph in the browser. It cooks live, draws with the same GPU renderer used on the desktop, and exposes the parameters you surfaced so visitors can play with them.
The exported folder holds an index page to open, your project as a .ntbundle (the graph plus its media), and the Web Player engine as a WebAssembly module and its loader. Drop that folder on any web host and share the link. The bundle carries the graph's subgraph definitions and the media files they reference as well as the ones in the top-level graph, so a piece built out of subgraphs travels whole.
The parameter list is not a separate file. Whatever you have pinned in the Parameters (Pinned) panel is what the page offers: a pinned parameter contributes itself, a pinned whole node contributes the parameters its card shows, and a pin made inside a subgraph is left out, because the page addresses nodes in the top-level graph only. A name you have renamed in the panel travels with it.
Nothing else about a parameter is baked into the export. The page asks the running engine what each one is and what it accepts, and builds a slider, a text box, a fixed dropdown or a type-to-filter combobox to match, so a control always offers what the node offers today. The list is re-read each time you open a dropdown, which is how a camera picker fills in with the devices on the viewer's machine. Controls open at the value the graph is set to rather than the parameter's default, a stored option that is no longer available is shown as (not available) rather than silently swapped, and a change the engine rejects is reported on the control instead of being swallowed. Expose only what people should touch. See Parameter widgets.
The Full App needs WebGPU. The page checks for it on load and stops with a message naming Chrome 113+, Edge 113+ or Firefox Nightly. If you are sharing widely, say which browser to use.
Audio Only
For a project that is sound rather than visuals, the Audio Only build strips out everything graphics-related and ships the audio engine alone, a fraction of the Full App's download size. It plays the audio graph live in the browser through an AudioWorklet, either autoplaying or waiting for a click, on a page whose background and accent colours you set.
That is the design. It does not run: the panel starts every export without the graph's audio plan, so an Audio Only export fails immediately, and the browser-side audio runtime is not built into the repository by default. See Audio export.
Web Player limits
The browser is a sandbox, so the Web Player is limited compared with the desktop app.
The Full App has no audio output, and no native live inputs or outputs. No MIDI, OSC, DMX, NDI or Syphon. Live work belongs on the desktop; build a web piece around exposed parameters instead. See Inputs and Outputs.
The two halves of that fail differently, and neither is obvious from the panel.
An OSC, DMX, NDI or Syphon node stops the export before it starts, naming the node and what the web target cannot provide. So does anything that reads a file, which is why a graph with an Image node cannot be exported as a Full App at all. Camera Input is refused the same way, even though the browser runtime does run the webcam through the browser's own camera API with a working device picker: the capability the check tests for is not one the web target claims, so the node the browser could actually serve is the one the export turns away. See Exporting for the full list.
MIDI, audio output and gamepad nodes fail the other way. The web target claims all three, so the export runs, the page loads, and nothing arrives.
When the page will not behave
The browser console is the place to look. WebGPU errors the page never catches are printed there rather than leaving a black canvas with no explanation, along with the display format and size the page settled on, which is usually what differs between the machine it works on and the one it does not.
For more detail, add ?nt_log= to the page's URL with the same directives a desktop run takes, for example ?nt_log=info for the ordinary stream or ?nt_log=info,cook_breakdown=debug to watch what each cook spends its time on. A directive the runtime cannot parse is reported in the console and the normal filter stays in force, so a typo costs you nothing but the detail you were after.