HTML in Canvas lets DOM live inside a canvas element

A few years ago, teams building rich, interactive visual apps faced a stark choice. The DOM offered instant text layout, copy-and-paste, right-click menus and built-in accessibility, but it could not deliver the pixel-perfect graphics that games or 3-D editors need. Canvas, WebGL and WebGPU gave low-level control over a raster of pixels, yet everything inside a canvas was just a bitmap, no selectable text, no screen-reader support, no in-page search.

The new experimental HTML-in-Canvas API, now available in an origin trial for Chrome, removes that trade-off. It lets developers draw DOM nodes directly into a 2D canvas or a WebGL/WebGPU texture while keeping the UI fully interactive and accessible. The rest of this post shows why the choice existed, what the API does, and the concrete benefits for accessibility, search and extensions.

Readers will come away with a clear picture of how the bridge works and a concrete step to try the API in their own projects.

Why the DOM-vs-canvas decision mattered

The DOM is the foundation of web UI. It provides ready-made text layout, CSS styling, form controls and deep integration with browser features such as copy-and-paste, context menus, translation, dark mode, zoom and autofill. Because the DOM is semantic, assistive technologies can parse it, expose it to screen readers and include it in the page-wide find-in-page function.

Canvas, WebGL and WebGPU expose a raster of pixels that can be manipulated at a very low level. Games, design tools and other high-performance apps use this to render complex 2D and 3D graphics. Since a canvas is just a bitmap, developers must write custom code for text layout, selection, form widgets and other UI patterns. That custom code often inflates bundle size and still cannot tap into the browser’s native accessibility tree or search index.

Because the two stacks live in separate worlds, any UI drawn inside a canvas loses the DOM’s semantic and interactive advantages. The result has been a hard architectural decision: either accept the performance and flexibility of canvas and give up built-in accessibility, or stay in the DOM and forgo low-level graphics control.

What the HTML-in-Canvas API actually does

The API acts as a bridge. It lets a developer take a DOM element, such as a <div> with styled text, and draw it into a canvas or a WebGL/WebGPU texture. The browser synchronizes the element’s transformations with the canvas so that the rendered output stays in lockstep with the underlying DOM node.

While the element is rendered onto a texture, the original node remains in the accessibility tree. Screen readers, translation services and the find-in-page feature can locate and interact with the text even though it appears as part of a 3-D surface. Chrome DevTools can inspect the element, edit its CSS in the inspector and see the changes reflected instantly on the texture.

A concrete example from the trial documentation shows a developer calling the API to render a <div> containing styled text into a WebGL texture. The text appears on a rotating 3-D plane, but users can still select the text with the mouse, copy it with Ctrl-C, and locate it with Ctrl-F. A screen reader reads the text as if it were regular HTML, because the node stays in the accessibility tree.

Concrete benefits

• Accessibility, The DOM node stays in the accessibility tree, so assistive technologies parse it without extra work. Users of screen readers hear the same content that appears on a 3-D surface, and focus handling works unchanged.
• In-page search, The find-in-page command (Ctrl/Cmd + F) highlights matching text even when it lives inside a WebGL texture. The browser maps the search result back to the DOM element and draws the highlight directly on the texture.
• Indexability, Web crawlers and AI agents can read the rendered text because it exists as real HTML. SEO and content-extraction tools do not need special heuristics for canvas-only graphics.
• Extension integration, Browser extensions that manipulate page text, such as translators or ad blockers, operate on the DOM node and automatically affect the rendered texture. Replacing a word in the DOM updates the texture without additional extension code.
• Developer-tool support, Chrome DevTools can inspect the DOM element inside the canvas, let developers tweak CSS live, and show the updated texture instantly. This removes the need for separate debugging pipelines for canvas UI.

These advantages collapse the previous gap between high-performance graphics and the rich ecosystem of browser-level features. Applications that already rely on large canvases, design tools, data visualizations or immersive 3-D editors, can now embed native HTML controls without sacrificing performance or accessibility.

The takeaway

The HTML-in-Canvas origin trial eliminates the historic trade-off between DOM semantics and low-level graphics. By drawing DOM nodes into canvas or WebGL textures while preserving their interactivity, developers gain built-in accessibility, searchable text and native extension support without extra code. Try the API in a small prototype and verify that UI elements remain selectable, searchable and inspectable inside a 3-D scene.

The HTML-in-Canvas API origin trial provides the official documentation and sample code.