What WebGPU Means for Image Tools

Every tool on this site runs its AI model inside your browser tab, on your hardware, and never uploads your photo. That design is only a few years old as a practical option, and the reason it became practical is WebGPU. This is the technical version of why.

What WebGPU actually is

WebGPU is a JavaScript API for talking to the GPU. It is the successor to WebGL, but calling it "WebGL 2" undersells the change, because the two are aimed at different things.

WebGL was a graphics API, descended from OpenGL ES, and its world is triangles, vertices, and fragments. People did run neural networks on it, by an ingenious and slightly grim trick: encode your tensors as textures, write your matrix multiply as a fragment shader, and let the rasteriser do the arithmetic while pretending to draw a picture. It worked, but it fought the API the whole way.

WebGPU is modelled on the modern native APIs (Vulkan, Metal, Direct3D 12) and exposes compute shaders as a first-class thing. You write a kernel in WGSL, allocate real buffers, dispatch a workgroup grid, and read the results back. No textures, no pretending, and much lower per-call overhead. A convolution is a compute problem, not a drawing problem, and now you can express it as one.

Why this changed the economics

Here is the thesis of the whole site, stated plainly.

An image tool that runs its model on a server pays for a GPU. That GPU costs money per hour whether or not anyone shows up, and each image costs a fraction of a cent to a few cents in compute. Small per image, relentless in aggregate, and it forces the business model. You have to meter. So you get credits, watermarks on the free tier, a sign-up wall, a resolution cap, three free images then subscribe. That is not greed exactly. It falls out of the arithmetic: unlimited free means unbounded cost, and unbounded cost is not a business.

Move the model into the visitor's browser and the marginal cost of an image becomes zero. Not low, zero. Your GPU does the convolutions. The operator serves a static model file once, gets it cached, and after that an extra image costs nothing. So "free and unlimited" stops being a loss-leader to be recouped later and becomes an honest description of the cost structure. Loss-leaders end the same way, with the free tier degrading once the funding does. There is nothing here to degrade.

Privacy comes along for free, and it is worth being precise about why. Your photo never leaves your machine, not because we promise not to look, but because there is no upload endpoint to send it to. That is a structural claim, not a policy one, and you can check it in the Network tab. It cuts the other way too: we could not offer server-side history, shared links, or cross-device sync without breaking that property, so we don't. The privacy page has the full picture, and the comparison pages are candid about where paid tools beat us.

How much faster is it, really

Roughly 5x to 60x over WebAssembly, depending on the model. The range is wide because it is not one number, and the spread is the interesting part.

What decides where you land is arithmetic intensity: how much maths the model does per byte it moves. A dense convolution stack is nearly ideal, thousands of independent multiply-accumulates per pixel, embarrassingly parallel. That is the top of the range. Models with many small sequential ops, awkward reshapes, or control flow spend their time moving data instead of computing, and the GPU's lanes sit idle waiting on memory. That is the bottom.

Fixed costs matter too. Getting your image into a GPU buffer and back out has real overhead, and on a small image that eats most of the win. On a 4000 pixel scan it disappears into the noise. The bigger your image, the better WebGPU looks, which is convenient, because big images are when you care. In felt terms, on a mid-range laptop: the difference between a background removal that returns while you are still looking at the image, and one where you wonder if the tab has crashed.

Browser support in 2026, honestly

Chrome and Edge on desktop are good. This is the mature path: WebGPU shipped in Chrome 113 in 2023, it has had years of hardening, and it is where these tools were developed and tested.

Safari and Firefox are further behind. Both have shipped it, and both are rougher in practice than the support tables suggest, with more driver-specific quirks and more of the long tail of shader edge cases still being filed off. It broadly works. It works less predictably.

Mobile is patchy, and this is the honest weak spot. Support depends on OS version, GPU vendor, and driver, and the failure mode is less "it is missing" than "it is present and behaves strangely". Even where it works, a phone has less memory and a thermal budget: it will run fast for twenty seconds and then throttle. Mobile is where you are most likely to land on the fallback path, and where that hurts most. None of this is stable enough to hard-code, so we feature-detect at runtime.

The fallback, and why it exists

When WebGPU is unavailable we fall back to WebAssembly. WASM runs the same model on your CPU, through the same runtime, and it is what makes the tools work at all on a browser that has not caught up.

It is genuinely slow, and we say so in the interface rather than hiding it behind a spinner. The worst case is single-threaded WASM, which happens when cross-origin isolation is unavailable and SharedArrayBuffer is off, so the runtime cannot use threads. One CPU core, doing every convolution in a model that wanted a GPU. On a large image that is tens of seconds, and it can be minutes.

The alternative would be a progress bar implying everything is fine while your laptop fan spins up, and then you blame the tool rather than the situation. If you are on the slow path you should know, because the right move might be a desktop Chrome, or a smaller image.

The memory ceiling nobody mentions

A browser tab is not a workstation. A WASM heap tops out around 2 GB in practice, and even on the WebGPU path you work inside a constrained allocation, with a browser that will kill the tab rather than let it take the machine down. This ceiling shapes almost every engineering decision here.

It is why the models are small and quantized. Our object remover is the heaviest thing on the site; the full-size version of an architecture is often four times larger, a download nobody waits for and an allocation the tab might not survive. Shipping half precision instead of full precision halves both the download and the footprint for a quality loss you cannot see on a photograph, and some fallback paths go down to four bits per weight, where the trade becomes visible but the alternative is not running. Every model here was picked with that ceiling in mind rather than for its benchmark scores.

It is why the upscaler tiles. A 4x pass on a 2000 x 3000 image would need to hold an 8000 x 12000 output in memory at once, plus activations, well past what a tab will give you. So we cut the image into tiles, run each, and stitch with overlap so the seams do not show. Tiling is the only reason large images work at all, and the upscaling guide covers the size limits that fall out of it.

And it is why the colorizer runs at a fixed small size without capping your resolution. It predicts only chroma, so we run the expensive part small and apply the resulting colour over your original full-resolution luminance. That stage never touches your detail. This is the kind of thing you design when 2 GB is the wall.

How to check your own browser

The direct way, in your browser's console:

if (navigator.gpu) {
  const adapter = await navigator.gpu.requestAdapter();
  console.log(adapter ? "WebGPU is available" : "No adapter");
} else {
  console.log("No WebGPU in this browser");
}

The two failure cases are distinct. If navigator.gpu is undefined, the browser has no WebGPU at all. If it exists but requestAdapter() resolves to null, the API is there and the browser could not give you a GPU: usually a blocklisted driver or a headless environment. Both land you on WASM, for different reasons.

In Chrome, chrome://gpu lists the status of every graphics feature, and when WebGPU is disabled it usually says why, often a driver blocklist entry you can fix by updating the driver. You do not have to run any of this: the tools detect it and tell you which path you are on.

The honest trade-offs

On-device is not strictly better than server-side. It is a different trade, and here is the bill.

You pay a first-run download. The model has to reach your machine before anything happens: tens of megabytes for the lightest tool, a few hundred for the heaviest. A server-side tool has no such wait, because their model already sits in their GPU's memory. Ours is cached after the first run, so it is a one-time cost, but the first time you use a tool you wait for something they would not make you wait for.

It runs on your hardware, not theirs. A datacentre A100 will beat your laptop, and on a five-year-old machine with integrated graphics a server tool will be faster than us. Big images are harder for us, too: the 2 GB ceiling is our problem, and a server with 80 GB of VRAM never thinks about it. We also cannot ship the biggest models, because some of the best checkpoints are simply too large to send to a browser, whatever their license says.

What you get back: your photo never leaves your machine, there is nothing to meter, no watermark, no sign-up, no credit balance, and the tools keep working offline once the model is cached. For a scan of your grandmother, most people take that trade. For a 12000 pixel commercial render on a decade-old laptop, maybe not, and we would rather say so than pretend the trade does not exist.