Chrome Tests HTML-in-Canvas API for Interactive Canvas Content

On October 22, the Chrome team introduced an experimental HTML-in-Canvas API and opened an origin trial for it. According to the announcement, the API can render HTML content in 2D Canvas or use it as a texture in WebGL and WebGPU. The elements remain interactive and retain access to browser features. For now, this is a trial—not a reason to move a conventional website’s interface into Canvas.

Why Graphics Applications Need HTML

The DOM and Canvas have different strengths. HTML already handles text layout, forms, and conveying the meaning of content to the browser. Users can select and copy text, find it on the page, or use accessibility tools to interact with the interface. Canvas gives applications control over complex 2D and 3D graphics. But when the entire interface is drawn as pixels, familiar HTML behavior has to be recreated separately.

The new API lets developers place a DOM element inside <canvas> and render it in a graphics scene. The content remains available to screen readers, translation tools, extensions, and developer tools. Text on the surface of a 3D object can be selected, while an input field embedded in the scene continues to work as an HTML element. The announcement also says search crawlers and AI agents will be able to read that text.

This is more than a snapshot of HTML overlaid on an image. The browser needs to know where the rendered element is on screen; otherwise, clicks, hover interactions, and text selection will not line up with what the user sees. So, alongside rendering, the developer synchronizes the DOM element’s position with its image in Canvas.

How the API Works and the Trial’s Limitations

First, a layoutsubtree attribute is added to <canvas>. It tells the browser about the nested HTML content and makes it available in the accessibility tree. In a 2D context, the element is rendered with drawElementImage during the paint event. The method returns a transform, which is then assigned to the CSS transform property so the interactive area matches the rendered element.

For WebGL, texElementImage2D creates a texture from HTML; in WebGPU, the corresponding method is copyElementImageToTexture. Mapping coordinates is more complicated here: the element’s position on screen depends on how the scene uses the texture. The announcement shows how to align 3D scene coordinates, the HTML element’s dimensions, and the Canvas area using transforms and getElementTransform. Experimental support for the feature has already appeared in Three.js; PlayCanvas also has a way to work with it.

The origin trial is planned for Chrome 148–150. To try the API yourself, the article recommends Chrome Canary 149 or newer with the chrome://flags/#canvas-draw-element flag enabled. To test it on a website with other users, you need to register for the origin trial. When setting up Canvas, screen pixel density matters: otherwise, the content may look blurry.

The technology has limits. It does not work with content from a cross-origin iframe, for security and privacy reasons. Also, HTML inside Canvas is rendered with JavaScript. Scrolling and animation in such an interface cannot update independently of it in the way they can outside Canvas. Before putting a scrollable area there, it is worth checking how it behaves under load.

What This Means for Projects

Developers building large graphics workspaces and 3D scenes will be able to use standard HTML components where they previously had to implement text handling and controls themselves. The examples include a 3D book with HTML pages, an interactive slider, and typography distorted by a graphics effect. The visuals change, but the content remains available for standard user interactions.

For website owners and marketers, the more important question is whether the project needs that kind of scene at all. The API could be useful if someone needs to interact with text or a form directly within complex graphics. But it does not make Canvas the default choice for a promotional page. For now, it is more useful to follow the trial and test a specific use case: accessibility, hit-testing accuracy, input, and scrolling.

My Take

What interests me most here is not the effect of HTML on a 3D surface, but the chance to avoid building a second, stripped-down version of the browser interface inside a graphics application. If text can be selected, searched, and passed to a screen reader, the team has more freedom in how it renders the interface.

But I would not choose an architecture based on an impressive demo. I would first look at load and scene-update profiles, then test input and scrolling in a real interface. For a simple landing page, a simpler rendering approach and lightweight JavaScript are usually easier to understand. If an application already lives in Canvas, though, this trial is worth watching.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. The HTML-in-Canvas API origin trial developer.chrome.com

About the author

Jānis Ozols

Frontend architect

I build online store interfaces in Riga and work on frontend performance and infrastructure. I like finding bottlenecks through loading profiles, not guesswork.

All posts by the author