v0.1.4035 Nov 2026·Rendering, JavaScript & JIT, Web APIs & DOM, Privacy & Shields, Memory & reading, Tabs & interface

WebGPU is here

WebGPU is here. Pages can now use a modern graphics and compute API, drawn and computed on the real GPU, with the official conformance suite passing 96.1% of the cases it ran and the four public samples we tried running live. A test cube matches the reference browser on every pixel we compared. It is built to give a site less than the reference does: one identity for every machine, no GPU clock, and memory charged before it is allocated. Running that suite also found crashes a page could cause, and those are fixed here too. This release also closes a serious privacy hole: until now a page could read back the pixels of an image from another site through a canvas. The GPU row moves 65 to 75 and the overall score 74 to 75.

Parity with the reference browser

75overall, as of v0.1.405

Security architecture72

DevTools / extensions73

Web APIs / DOM surface75

GPU / graphics acceleration77

Networking85

Media85

Accessibility85

Real-world site compatibility99

HTML parsing100

CSS parsing + selectors100

Layout: block / flex / grid / tables / writing-modes100

Paint + visual100

JavaScript language100

JavaScript performance (JIT)100

HTML parsing100

WebGPU, measured

Before: A cube drawn with WebGPU: Floati without WebGPU, with it, and the reference browser. — BeforeFloati

After: A cube drawn with WebGPU: Floati without WebGPU, with it, and the reference browser. — Afterv0.1.403

The same page in the reference browser — Reference browserfor comparison

BeforeAfter

WebGPU is the modern way for a page to use the graphics card, for drawing and for computing. We built it on our own binding, in three layers: the page's objects and checks, a plain-data wire between them, and the GPU library behind it. To judge it we ran the official conformance suite through the real app and counted what happened rather than what we hoped. Of the cases it could run, 96.3% of the validation tests and 95.0% of the operation tests pass. A test cube with depth, 4x antialiasing and a texture matches the reference browser on all 160,000 pixels, and a triangle on all 76,800. A spinning cube runs at about 30% of a core, and four public samples run. There are honest gaps: workers, external textures from video, and frames still pass through the processor on the way to the screen.

Conformance cases passing, of those run96.1%Validation21,460 pass, 818 fail, 2 time outOperation3,206 pass, 163 fail, 6 time outPixels off the reference, test cube0 of 160,000Public samples running4 of 4 tried

Less for a site to read

The reference browser tells a page its GPU's vendor and family, and a list of optional features that varies by machine. Together those are a good fingerprint, and a GPU clock adds a way to measure what else the machine is doing. We give every machine one identity: the same name, the same limits, no optional features, and no clock. A page that needs a feature the identity does not offer will not get it, and that is the trade we chose. The same care went into memory: every allocation is charged before it happens, and objects a page lets go of are really freed.

Optional features shown0GPU clocknoneMemory per device1 GB, charged firstLive objects after 20,000 bind groupsunder 16

Pixels that are not yours to read

While wiring up texture uploads we noticed that the flag we thought guarded canvas reads only tracked fingerprinting, and nothing tracked which site an image came from. So we tried it in the real app: a page on one address drew an image from another and read its pixels back. A browser must never allow that: a picture meant only for you could be read by any page you visit. Now every image carries a verdict from the moment it arrives, and an image with no verdict counts as another site's. You still see cross-origin images on a canvas as normal; the page just cannot read them back, the same rule the standard sets.

Ways of reading checked in the real appgetImageData, toDataURL, WebGL, ImageBitmap, redirectsReads of another site's pixels left0

What the test suite found

The best thing a conformance suite did for us was crash. Running it through the real app, the browser died in the Apple graphics driver, and the cause was one pipeline setting that the GPU library leaves unchecked. Then a WebGL suite run showed that a nested shader ended the process, and a look at the same code turned up something worse in plain JavaScript: new ArrayBuffer(1e20) panicked the engine. All of these had been reachable by any page, and the last two were in earlier releases. Each now has a check before the work happens and a law in the test gate, and a sweep of 21 hostile sizes across the page APIs no longer finds a crash.

Crashes a page could cause, fixed3Hostile sizes swept, crashes left21, 0

What changed 35 changes

Rendering	Security: a page could read the pixels of an image from another site by drawing it on a canvas or loading it into a WebGL texture. Those pixels now stay out of reach: a canvas that takes them refuses to be read, a texture refuses them, and the mark follows them through other canvases, patterns, image bitmaps and redirects. Earlier versions had the hole.
Rendering	FIX: an image from another site set from a script fires load with its real size. It fired error and reported size 0, because the body was thrown away.
Rendering	FIX: the crossorigin attribute on an image makes a real CORS request, so a texture from a CDN that allows it loads and can be used.
Rendering	FIX: an image in the page's markup reaches script when it lands. naturalWidth stayed 0 and a canvas drew nothing for images that arrived after the page's scripts ran.
Rendering	FIX: an ImageBitmap uploads to a WebGL texture, keeping its own orientation and its premultiplyAlpha setting.
Rendering	WebGPU: navigator.gpu, adapters, devices, buffers, mapping, shader modules, bind groups, compute pipelines and passes, error scopes, and device loss.
Rendering	WebGPU: textures, views, samplers, render pipelines and passes, depth and stencil, 4x multisampling, render bundles, occlusion queries, every copy, and compile messages with line numbers.
Web APIs & DOM	WebGPU: getContext('webgpu') on a canvas and on an OffscreenCanvas, with frames that reach the page, toDataURL and drawImage. Frames still go through the processor on their way to the screen, which a later release removes.
Web APIs & DOM	WebGPU: a canvas holds one read in flight, so a page that draws faster than the screen drops frames instead of queueing work without limit.
Memory & reading	WebGPU: last frame's texture stops working when a new frame starts, so a page cannot keep a canvas's memory by holding on to it.
Privacy & Shields	Privacy: every machine shows one WebGPU identity: the same adapter name, the same limits, and no optional features, which are the usual way to tell GPUs apart. A timestamp query is refused, so a page gets no GPU clock.
Memory & reading	Security: GPU memory is charged before it is allocated, at most 1 GB per device and 2 GB per process, with limits on objects, queries, shader size and devices. A page that asks for too much gets an out-of-memory error, not a slow machine.
Rendering	Security: copying a cross-origin image into a texture is refused, so a page cannot read one back through the GPU.
Memory & reading	Memory: objects a page lets go of are freed by the VM's own collection of their wrappers, so a view or bind group made every frame leaves nothing behind. 20,000 bind groups leave under 16 live objects, and 80 quarter-GB buffers never run out.
Rendering	GPU: clear colours on 8-bit targets are snapped to a whole level, because 0.1 of 255 is exactly 25.5, a tie that Apple Silicon rounded up and DirectX 12 rounded down.
Memory & reading	FIX: a compute shader could ask for far more workgroup memory than the limit, directly or through an override. The GPU library leaves this to its embedder, so we count it ourselves.
Rendering	FIX: a render pipeline with alpha to coverage on an integer format ended the whole browser in the Apple graphics driver. It is a validation error now. The conformance suite found this one.
Web APIs & DOM	FIX: an empty vertex or index buffer range lost the page's GPU device. It now reaches the draw as nothing bound, which is the error it should be.
Rendering	FIX: a write mask past 15 and a second map on a buffer still mapping are validation errors. They were accepted.
JavaScript & JIT	FIX: new ArrayBuffer(1e20) and new Uint8Array(1e20) panicked the engine, from one line of a page. A page's number reaches the allocator only after a check now, buffers stop at 4 GB, and the answer is a RangeError.
JavaScript & JIT	FIX: a deeply nested WebGL shader, such as 10,000 additions in a row, ran the compiler out of stack and ended the process. Expressions, statements and calls now stop at the reference's depth of 256.
Rendering	FIX: a few lines of WebGL functions that each call the next twice would have inlined a billion operations. Inlining now has a bound.
JavaScript & JIT	FIX: a WebGL function may be defined after main calls it, through a prototype. It was refused, and this is common in real shaders.
Web APIs & DOM	FIX: DataView checks its range: a bad offset or length is a RangeError, and a read or write past the end throws. It returned NaN and ignored writes.
JavaScript & JIT	FIX: typedArray.set throws on a bad offset and takes array-like objects, checking the length first.
Web APIs & DOM	FIX: window.postMessage delivers as a task of its own, later than the code that posted it, with a clone of the data and a real event. It ran on the spot, so a chain of posts could run the stack out, and event.stopPropagation did not exist.
Rendering	FIX: imports in a module cycle are filled in when their module runs. They stayed undefined.
Rendering	FIX: export function* is exported. It was missing from the module.
JavaScript & JIT	FIX: a typed array's constructor property, its length from undefined, and the RangeErrors on its offset and length follow the standard.
JavaScript & JIT	FIX: Object.keys, for-in, hasOwnProperty and in see a typed array's indices, and only those.
JavaScript & JIT	FIX: a typed array is no longer instanceof ArrayBuffer, so code that wraps a buffer stops copying a view and writing to the copy.
JavaScript & JIT	FIX: the in operator reaches a typed array's prototype, and ArrayBuffer.isView knows a DataView.
Web APIs & DOM	Performance: module graphs loading at the same time share what they fetch, at most 4 graphs run together, and the memo stays under 64 MB.
Rendering	Reliability: a page that opens many files at once no longer runs the process out of file descriptors.
Tabs & interface	Testing: the official WebGPU conformance suite runs through the real app, and the WebGPU laws run on DirectX 12 in the Windows stage of the gate.