For the first time, a browser can paint your real, interactive HTML directly into a <canvas> and let WebGL shaders distort it in real time — while text stays selectable, links stay clickable, and the accessibility tree stays intact. The WICG HTML-in-Canvas proposal makes this possible, and the open-source Canvas UI library already ships 33 production components built on it. Verdict: the API is genuinely transformative for creative web work, but only the pure-WebGL half of Canvas UI is safe to ship to production today; the HTML-in-Canvas half needs a Chrome flag or origin trial and should stay on demo sites and code-based video pipelines for now.
What is HTML-in-Canvas?
HTML-in-Canvas is a WICG proposal, incubated in open standards, that adds a way for a <canvas> element to lay out and paint live DOM content, then let you draw that content into 2D and 3D canvas contexts. Up to now, canvas and HTML lived in separate universes: canvas gave you raw GPU pixels, HTML gave you layout, accessibility, and form controls, and you had to pick one. The proposal closes that gap with three new primitives (WICG explainer):
- The
layoutsubtreeattribute, which opts canvas children into layout so the browser knows they should be measured and painted by the canvas rather than at the top level. - The
drawElementImage()method on the 2D context, which draws a real DOM element into the canvas and returns the CSS transform you need to apply so hit-testing and the accessibility tree line up with where you drew it. - A
paintevent on the canvas that fires after the browser's own paint step, only when something actually changed, so you do not burn arequestAnimationFrameloop redrawing every frame.
The same proposal adds WebGL and WebGPU cousins — texElementImage2D uploads an element's rendering as a WebGL texture, and there is a copyElementToTexture path for WebGPU — so you can pull a live DOM element in as a texture inside a 3D scene. The crucial difference from every prior hack is that the element stays a real DOM node: it lives in the accessibility tree, participates in tab order, responds to keyboard focus, and updates the canvas when it changes. No screenshots, no iframes, no re-rendering (equero writeup, Codrops tutorial).
Why do we need it? The two options problem
Before this proposal, putting a GPU effect over your HTML content meant one of two bad options. Option one was to rebuild your content inside a canvas — drawing your own text, writing your own layout engine, hand-rolling form controls. The moment you did that, <select>, accessibility, find-in-page, and translation all broke. This is why tools like Figma had to build a browser inside a browser, and Google Docs runs its own layout engine. Option two was essentially to screenshot your DOM and draw a picture of it — the approach libraries like html2canvas take. That library's own FAQ states flatly that "as each CSS property needs to be manually coded to render correctly, html2canvas will never have full CSS support," and known issues like rotated-text capture have stayed open for over a decade (html2canvas FAQ, html2canvas docs).
HTML-in-Canvas fixes both by letting the browser render the HTML at full fidelity, inside the canvas, with all of CSS, layout, and accessibility intact. Think of it as shaders for HTML — or, if you were around for it, a reincarnation of what Flash let you do visually, except built into the open web platform.
What is Canvas UI?
Canvas UI is the first open-source component library built on the HTML-in-Canvas API. It was released in July 2026 by developer David Haz (GitHub: DavidHDev) and advertises 33 framework-agnostic components that draw real HTML inside a canvas with WebGL effects running over it (canvasui.dev, GitHub repo). The library splits into two tiers:
Components that need HTML-in-Canvas (experimental half): Liquid, Blaze, Glass, Shatter, Bubble, Grid, Ripple, Decrypt Reveal, VHS, and more. These read your live DOM as a texture and distort it with shaders — fire warps the page, liquid glass refracts what is underneath, text decrypts character-by-character at the cursor. They deliver the "wow" effects that the demo videos highlight.
Components that are pure WebGL / Three.js (stable half): ASCII Object, Glass Object, Particle Object, Dithered Object, Liquid Object, and other 3D scene components. These do not need the experimental flag at all and run in every modern browser today, since WebGL support is universal (Can I Use: WebGL, MDN: WebGL). This is the half the README explicitly recommends shipping on production landing pages and marketing sites.
The table below summarises the split.
| Category | Examples | Needs Chrome flag? | Safe to ship today? |
|---|---|---|---|
| HTML-in-Canvas effects | Liquid, Blaze, Glass, Shatter, Decrypt Reveal, VHS, Bubble, Grid, Ripple | Yes (or origin trial) | Demo + video only |
| Pure WebGL / 3D objects | ASCII Object, Glass Object, Particle Object, Dithered Object | No | Yes, all modern browsers |
| Fallback mode (no flag) | WebGL overlay version of the above | No | Yes, degrades gracefully |
The graceful degradation is the part that makes the library usable: when HTML-in-Canvas is not present, your content renders as normal HTML and the parts of the effect that can still run as a pure WebGL overlay keep running. Nothing breaks (Canvas UI FAQ).
How do you install a Canvas UI component?
Canvas UI is distributed through a shadcn-compatible registry, which means you do not install a package — you copy the source into your project with one command and own it from there. The pattern matches how the shadcn/ui CLI works more broadly: the CLI pulls the full component source into components/canvasui/ (or whatever your components.json points at), pulls in dependencies like Three.js where the component needs them, and leaves you free to read, restyle, and version the file like any other code you wrote (shadcn CLI docs, Canvas UI quick start).
To add, for example, the Particle Reveal effect to a React project:
npx shadcn@latest add @canvas-ui/particle-reveal-react
Swap particle-reveal for any component name and react for solid, preact, vue, svelte, or vanilla — every component ships in all six framework flavours built on the same engine with the same props. Most components simply wrap your content:
import { ParticleReveal } from "@/components/canvasui/ParticleReveal";
export function Hero() {
return (
<ParticleReveal radius={300}>
<YourContent />
</ParticleReveal>
);
}
The subtree inside stays live and interactive; the shader runs on top.
Can an AI agent install these components for you?
Yes, and this is where Canvas UI becomes interesting for people building AI-assisted workflows. The registry speaks the shadcn protocol, so any assistant with the shadcn MCP server can browse the library, read the docs, and install components from a single prompt (Canvas UI docs: MCP). Setup is one command:
npx shadcn@latest mcp init --client claude
It works with Claude Code, Cursor, VS Code, Codex CLI, and OpenCode. After that you can literally ask your agent — "add the Liquid component from Canvas UI to my hero section" — and it reads the registry, runs the install, and wires the file into your project. The docs site also exposes "Copy for AI," an llms.txt, and one-click "Open in ChatGPT / Claude / v0" buttons on every component page so the model gets a configured, context-ready prompt rather than a raw code dump.
If you want a deeper look at how an agent-friendly design skill keeps code quality high when AI installs components for you, see our breakdown of the Impeccable design skill for fixing AI slop in coding agents; and for the broader pattern of running Claude Code without paying full subscription price, our guide to using Claude Code for free in 2026 covers the MCP-server setup in more detail.
Which browsers support HTML-in-Canvas today?
This is the single most important fact to understand before you build anything on it: the API is not shipped. It is a living WICG explainer, actively iterated on, and implemented behind the chrome://flags/#canvas-draw-element flag in Chromium only. Firefox and Safari have not announced implementation; Mozilla's standards position is still under discussion (Mozilla standards position thread, imiel.dev primer). For production sites, Canvas UI documents an origin trial token that lifts the flag requirement for your visitors — which is how the canvasui.dev site itself runs in a plain Chrome install — but an origin trial is a temporary opt-in, not a commitment to ship the feature.
| Browser | HTML-in-Canvas components | Pure-WebGL / 3D components |
|---|---|---|
| Chrome / Edge with flag or origin trial | Full effect | Full effect |
| Chrome / Edge without flag | WebGL overlay fallback | Full effect |
| Firefox | WebGL overlay fallback | Full effect |
| Safari | WebGL overlay fallback | Full effect |
The fallback is the part that makes the library honest about where it stands: when the flag is missing, your page does not break. Liquid becomes a normal page, Blaze becomes a lower-fidelity fire effect, Bubble becomes a plain bubble. The visitor on Firefox still gets a working page — they just do not get the heat-distortion-on-real-HTML layer.
A niche use case that works today: code-based video effects
If you are not a video editor but you can write (or prompt for) code, there is one Canvas UI use case you can ship today with no browser-flag concerns: using the effects inside code-based video tools like Remotion. Remotion treats every video frame as a React component, which makes it a natural fit for AI-assisted video generation — the agent generates readable, editable React code rather than a black-box video file, so you can inspect, version, and iterate (Remotion GitHub). Because Remotion renders in a controlled, Chromium-based headless environment, you can enable the HTML-in-Canvas flag there regardless of what your end viewers' browsers support, then bake the effect into the output MP4.
The practical pattern is: pick a Canvas UI effect (VHS, rain, glitch), ask your coding agent to apply it as a filter on a webcam clip inside a Remotion composition, render, and export. You are effectively coding video effects — adding a VHS look, switching to rain, dropping in glitches — through natural-language prompts against the same component source you would use on a web page. For a broader look at the same "video-as-code" idea for AI agents, see our walk-through of a Claude AI video editing workflow for B-roll fixes.
Is Canvas UI worth using?
Yes — selectively. The pure-WebGL overlay effects (the 3D objects and the gracefully-degraded versions of the fluid effects) work in every modern browser, are MIT + Commons Clause licensed, cost nothing, and are exactly the kind of tasteful GPU effect a landing page or marketing site benefits from. The full HTML-in-Canvas experience is genuinely magical and a glimpse of where the web is heading, but until the proposal lands in more than one browser engine it belongs on demo sites, in portfolio pieces, and — most pragmatically — inside code-based video pipelines where the rendering environment is yours to control. The library's honesty about its own limitations (graceful fallbacks, explicit browser-support table, origin-trial documentation) is what makes it usable rather than just a flashy demo.
The longer-term bet is the standard itself. If drawElementImage ships in Firefox and Safari, it will obsolete html2canvas, the foreignObject-in-canvas trick, and the invisible-overlay pattern in one stroke — every creative-tool, chart, game-UI, and image-export workaround that exists today because the platform had no answer would suddenly have a real answer. Watch the WICG repo; that is where the next move on this happens.
What this means for you
- If you build marketing sites or portfolios, install one or two of the pure-WebGL Canvas UI effects with the shadcn CLI today — they are free, framework-agnostic, and run everywhere.
- If you make code-based videos with Remotion or a similar React pipeline, the experimental HTML-in-Canvas effects are safe to use because you control the render environment.
- If you ship to a general audience on the public web, hold off on the HTML-in-Canvas-only effects until the API or a stable origin trial reaches Firefox and Safari. Use the WebGL-overlay fallbacks until then.
- If you work with an AI coding assistant, point its shadcn MCP server at the Canvas UI registry so it can install and wire components from a single prompt — the same pattern works across Claude Code, Cursor, Codex, and OpenCode.
FAQ
Q: Is HTML-in-Canvas a shipping browser feature?
A: No. It is a WICG proposal implemented behind the chrome://flags/#canvas-draw-element flag in Chromium only. Firefox and Safari have not announced implementation. For production sites, an origin trial token lifts the flag for your visitors, but the API surface is still moving and the spec is a living explainer.
Q: Is Canvas UI free to use commercially? A: Yes. The library is licensed under MIT + Commons Clause, which lets you use every component in any personal or commercial app or website free forever. The only restriction is reselling or redistributing the components themselves, alone or in a bundle.
Q: Do the effects break on unsupported browsers? A: No. Components detect support at runtime. Without the flag, your content renders as normal HTML and the parts of the effect that can still run as a pure WebGL overlay keep running. Firefox and Safari users get a working, lower-fidelity page rather than a broken one.
Q: Do I need React to use Canvas UI? A: No. Every component ships in six flavours — React, Solid, Preact, Vue, Svelte, and dependency-free vanilla TypeScript — built on the same engine with the same typed props.
Q: How does Canvas UI differ from html2canvas? A: html2canvas re-implements DOM and CSS rendering inside a canvas and will never fully support CSS (its own FAQ says so). Canvas UI uses the native HTML-in-Canvas API to paint real, live DOM into the canvas, so the element keeps full CSS fidelity, stays in the accessibility tree, and remains interactive.
Q: Will HTML-in-Canvas become a web standard? A: It might. It is in WICG incubation with a working Chromium implementation and active iteration, but standards need multi-engine buy-in, which is never guaranteed. The Mozilla standards position is still under discussion as of this article's last-verified date.
Discussion
0 comments