For twenty years, canvas in the browser has been an island: powerful, but blind to the rest of the DOM. Rendering HTML elements inside a canvas scene almost always meant a manual snapshot pass through something like html2canvas — fonts that do not quite match, features that break in unexpected tabs, a constant battle against the abstraction. Google I/O 2026 introduced an origin trial that changes this at the platform level: the HTML-in-Canvas API.
How it works
The API has three primitives. A layoutsubtree attribute tells the browser to lay out canvas children normally — same flow, same cascade. The methods texElementImage2D() and copyElementImageToTexture() push that layout as a texture into WebGL and WebGPU respectively, with the GPU driving the render. A paint event fires when children change, so you only re-upload when something actually changes. Critically, the DOM elements stay in the DOM — accessibility, find-in-page, translations, dark mode and even autofill all keep working as they always have.
Bigger than it sounds
Design tools, code editors and visualisation platforms have spent years building creative workarounds for this missing primitive — painting HTML into a canvas, rendering in a hidden iframe, relying on screenshots. The HTML-in-Canvas API moves the fix to the platform side, so fewer library abstractions are needed. There is an agentic web angle too: because the text stays in the DOM, AI agents and web crawlers can read canvas applications for the first time.
Our take
The origin trial runs in Chrome 148 through 151 — and no other browser engine has committed to an implementation yet. You can experiment today, but you cannot rely on it for broad-audience production work. Even so, this is the direction creative web applications have needed for years. If you build design tools, 3D environments or rich visualisations, tracking this spec now is worth your time.
