DocumentationDocumentation
User guide/Frontend development and delivery

Bring an existing Web UI into Blender

Reuse HTML, CSS, JavaScript, or a frontend build in a local window, then connect Blender actions, state, and file tools as needed.

Bring an existing web interface into Blender

Reuse your HTML, CSS and JavaScript, or keep the components and build workflow of a React, Vue or Svelte project. Package the browser-ready static output with your add-on and connect the Blender features you need. Your web interface runs inside Blender without rewriting its layout as native panels.

Route Requirements Deliverables
Plain HTML, CSS, and JavaScript Small tools or existing static pages Directly loadable page files.
Runnable third-party distribution files A real browser-ready entry provided upstream Pinned scripts, styles, and supporting assets.
Frontend project build Existing framework projects or bundled components Built static pages, with editable source retained for maintenance.

Small tools can use plain web files, while existing projects keep their current toolchain. The page handles layout, styling and components; your add-on's Python handles Blender operations. Connect the two where needed.

Three steps to bring your page into Blender

  1. Prepare the page. Keep the HTML, CSS, JavaScript and assets of a plain web page. For React, Vue and similar projects, create a production build and include index.html with the files it references. Reuse your existing components, themes and interactions.
  2. Open it in Blender. Embed the nexus_web framework in your add-on, bind the page's resource root, declare the entry with web.local_app("index.html"), and open it using web.window and your add-on handle. A Vite dist directory can be the resource root directly. If the page sits in a subdirectory of a wider resource root, set base: "./" so built assets resolve relative to the entry page.
  3. Connect the features you need. Keep the page's buttons and components. Connect operations that need Blender to registered Python actions, then use state subscriptions to bring scene data back to the interface. Ordinary web interactions continue to run in the frontend.

For a minimal add-on and its full lifecycle, see Build your first add-on; for an existing add-on, follow Integrate into an existing add-on to add web windows step by step. You can complete the entire workflow by writing code directly.

This workflow reuses frontend pages and build output that can run locally. The Blender bridge is available only to the add-on's trusted local pages; remote URLs and development-server pages do not automatically gain control of Blender. Features that rely on server rendering, databases or online APIs still need their backend and network access.

Extend your tools with existing web components

Component libraries provide the interface; your add-on provides the functionality. Keep your existing tables, charts, forms, node editors or canvas libraries, and connect them to scenes, files and custom operations through the public APIs.

Existing web capability What you can build in Blender How to connect it
Tables, search and filters Object lists, asset catalogs and batch-operation panels Subscribe to data published by the add-on and connect buttons to registered Python actions.
Forms, sliders and charts Parameter panels, scene statistics and task progress Submit input through actions and update the display from state snapshots. Use the dedicated undo API for interactive transforms.
Canvas and image-editing components Texture workspaces, asset organization and image import/export Use resource and file APIs to receive assets and save results, with adapters that follow the component's data model.
Node editors and custom interactions Your own workflow editors and specialist tool interfaces Implement the data and operation mapping in Python; web nodes do not automatically become Blender nodes.

These are ideas you can combine in your own tools. Follow Actions and state tutorial to connect your functionality. For React, Vue and Svelte state adapters and the Fabric.js resource adapter, see Frontend adapters and existing helpers. Supply third-party libraries in your project and check the versions and licenses you use.

Include all page resources

  1. Verify official entry points, versions, dependencies, and licenses. Do not guess global-script availability from a library name.
  2. Bundle the required fonts, icons, images, and assets referenced by CSS with the page as local files.
  3. Use relative local paths and configure build asset bases for the deployment location.
  4. Libraries handle their own controls; retain host dragging, transparent hit regions, and closing in the shell.
  5. Open dropdowns, dialogs, and overlays to check hidden content actually loads.

Separate development source from shipped files

Keep source, dependency manifests, lockfiles, and build configuration for maintenance. Ship only necessary static runtime output. Edit source and rebuild instead of maintaining minified-file edits. Recheck manifests when filenames include content hashes.

Use existing adapters for Vue, React, Svelte, or Fabric.js as needed. Adapters neither install third-party libraries nor replace resource-script ordering. See Frontend adapters and existing helpers.

Keep closing independent of application initialization

Put essential host operations such as closing in a separate external script so initialization failures do not trap users. Retain window, drag, and exclusion markers. Exclude dragging on custom component hosts using Shadow DOM.

Local pages prohibit inline JavaScript and onclick-style attributes. Classic scripts and ES modules are supported. Bare package imports need build resolution before delivery.

Check the actual page after building

  • Open the final output with complete styles, fonts, and images.
  • Resource URLs do not point to a developer's absolute paths or development server.
  • Keep Chinese font fallbacks and prevent excessive text overflow.
  • Check actions and input in the real local window; browser previews check only the page.

Read next: Page resource restrictions and Packaging and delivery.

Sources: frontend selection guide, public entry points and resource boundaries, action and state APIs, and frontend adapters.

Back to User guide · All topics