Chrome's HTML-in-Canvas Trial Runs in Versions 148 to 150, and Chrome's Post and the Spec Name the API Differently

Chrome's HTML-in-Canvas origin trial lets a page draw live DOM content, form fields included, into a 2D canvas or a WebGL or WebGPU texture, and it runs in Chrome 148 through 150, according to Google's developer post. The post is by Thomas Nattestad and Natalia Markoborodova, and its stamp reads last updated 2026-05-19.

That date matters. The post gives no start or end date for the trial, only version numbers, so anyone planning to use it on real users should check the trial's registration page before writing code against it.

What HTML-in-Canvas does in Chrome 148 to 150

Until now a canvas could hold pixels or shapes, and anything with text layout, form controls or selection had to be rebuilt by hand. The proposal lets the browser lay out ordinary HTML children of a <canvas> and then paint them wherever the developer wants.

The post says the content stays interactive: text selection, copy and paste, right-click menus, find-in-page highlighting inside a WebGL texture, and an accessibility tree that screen readers can read. It also lists indexing by crawlers and AI agents as a benefit.

Here is the surface Chrome's post documents:

Piece	Used with	Role
layoutsubtree attribute	<canvas>	Browser lays out and exposes child DOM
paint event, canvas.onpaint	Any canvas	Fires when the element redraws
ctx.drawElementImage(element, x, y)	2D context	Draws the element, returns a transform
gl.texElementImage2D(...)	WebGL	Uploads an element as a texture
queue.copyElementImageToTexture(...)	WebGPU	Copies an element into a texture

The 2D path is short. The developer sets layoutsubtree on the canvas, then in the onpaint handler calls drawElementImage and assigns the returned transform to element.style.transform, so the real DOM node sits exactly where its painted copy appears and keeps receiving input.

Trying it today

To test locally, the post says to use Chrome Canary 149 or later with chrome://flags/#canvas-draw-element. To enable it for visitors, a site registers for the origin trial. The post links four demos, among them a WebGL book with DOM-based pages and a WebGPU jelly slider.

Library support is experimental. Three.js has THREE.HTMLTexture, which takes a DOM element as the texture source, and PlayCanvas exposes htmlTexture.setSource(htmlElement), updating on the paint event.

Where the explainer and the post use different names

The Chrome post and the WICG explainer do not describe the same API surface. The explainer lists five primitives: a content attribute, a drawable attribute, the paint event, drawElementImage with WebGL and WebGPU equivalents, and updateElementGeometry. The Chrome post uses layoutsubtree and a getElementTransform method that the explainer's summary does not name.

The explainer also says to enable two flags in Canary, canvas-draw-element and enable-experimental-web-platform-features, while the post mentions only the first. The explainer calls itself "a living explainer which is continuously updated as we receive feedback," and Chrome's own post warns that "the implementation details might change." Treat any tutorial code as provisional until the two documents agree.

What the API will not draw

The security model is the reason the feature stays narrow. The explainer's rule is that painting "must not reveal any security- or privacy-sensitive information that isn't otherwise observable to author code."

In practice, cross-origin embedded content is excluded. The explainer notes that same-origin iframes would still paint, but cross-origin content inside them would not. Visited-link information, pending autofill data, spelling and grammar markers, system colours and IME pop-ups are on the same list. Chrome's post puts the limit in one sentence: "the API does not work with cross-origin iframe content."

There is a performance cost too. Because drawing happens in JavaScript, the post says "scrolling and animations cannot update independently of JavaScript," so a long scrolling page drawn this way loses the compositor's smooth path.

Who else supports it

The explainer's eight listed authors include Chromium and Igalia addresses, and it reports no position from any other browser. It says a synchronous paint step "has unique implementation challenges in Gecko, and possibly other engines." That leaves the feature as Chrome-only for now, behind a flag or a trial.

The next fixed point is Chrome 150, the last version the post names. Whether the trial extends past it is not on the page. The post lists issuetracker.google.com component 1400036 for bug reports.

Chromium-only web features are a recurring cost for browser-dependent teams; the Arc shutdown on December 22 is a reminder that a browser choice can change under a workflow, and a canvas-rendered UI that only Chrome can draw narrows the choice further. The same gap between a vendor's announcement and what ships appears in Respan's pre-alpha Rust gateway, where the benchmark claims came first.