Every free tool that runs on a rented GPU eventually asks you for something. An email address, a credit counter, a watermark, a thirty-second cap. Founders in that position are not being greedy — they are paying a bill per unit of work, and free users are a line item that grows with usage.

There is a way out of that arithmetic, and it is older than it sounds: run the work on the visitor's machine. Browsers now ship a GPU API (WebGPU) and hardware video codecs (WebCodecs). For a certain shape of product, that turns per-use cost into zero and changes what you are able to promise.

I have spent the last few months building one of these — a video and image upscaler where the file never leaves the browser — and the interesting part has not been the shaders. It has been discovering which parts of the business model this choice fixes and which parts it makes permanently harder. Here is the honest ledger.

What zero marginal cost actually buys

Not "cheaper hosting". The static site costs about the same either way. What it buys is a set of promises a server-based competitor structurally cannot match:

No account. Sign-up walls on free tools exist to attach a cost to a person. With no cost to attach, the wall has no job to do.

No cap and no watermark. Processing a hundred files costs exactly what processing none costs. There is no number to meter, so there is no credit counter and nothing to deface the output with.

Privacy you can prove rather than assert. This is the one that surprised me. Every tool site has a privacy policy; nobody believes any of them, because a policy is a promise about a server you cannot see. When the work happens locally, the claim becomes testable in ten seconds: open the page, disconnect from the internet, and it still works. A user who tries that once stops needing to trust you.

That third one is the real asset. The first two are features; the third is a position no funded competitor can copy without rebuilding their product.

Four questions before you try it

Most products fail at least one of these. Ask them in order and you will usually get your answer within a day.

1. Can the work be expressed in what browsers already ship? WebGPU for parallel compute, WebCodecs for video, WebAssembly for everything else. If your core operation needs a 40GB model or a CUDA-only kernel, stop here. Small convolutional networks, signal processing, image and video transforms, simulation, parsing, compression — all fine.

2. Is the input the user's own file? This approach works when the valuable data arrives from the user and leaves to the user. It does not work when your product's value comes from aggregating across users, because the data you would aggregate never reaches you.

3. Is a modern desktop browser an acceptable gate? WebGPU and WebCodecs together mean desktop Chrome or Edge today. Safari has WebGPU and is catching up on the rest. Phones technically qualify but have a fraction of the GPU memory, so long jobs fail part-way. You will turn away real visitors. Decide in advance whether that is a rounding error or your market.

4. Does your differentiation survive without a server-side moat? Anyone can view your source. If the thing you sell is the pipeline itself, this is a bad idea. If the thing you sell is the product around it — the defaults, the honesty, the fact that it just works — it holds up fine.

The bill you pay instead

Nothing is free; the costs move rather than disappear.

Performance becomes your users' hardware, and the variance is enormous. On my laptop GPU the shader-based methods produce a 1080p frame in about 6 milliseconds — roughly seven times faster than the footage plays. The neural method that produces the best quality takes about 345 milliseconds for the same frame, sixty times slower. Both numbers are true; which one a visitor experiences depends on a choice they do not yet understand, on a machine you cannot see. Designing that choice well turned out to be a larger job than implementing either method.

Support is blind. You cannot look at the file, because you never received it. When someone reports that their video will not load, you have no artifact to inspect. Everything has to be diagnosed in advance and explained on the page: which codecs decode, which do not, what a device is capable of before a file is picked rather than after.

You inherit the browser's gaps as your product's limits. Decoding runs on whatever the browser ships. H.264 and VP9 everywhere, AV1 on most current builds, H.265 and ProRes usually nowhere. That is not a bug you can fix; it is a sentence you have to write on the page.

You cannot measure your own quality in production. With no outputs on a server, "is this actually good?" has to be answered offline, against a corpus you build yourself. I ended up running a few hundred controlled comparisons on a real GPU because there was no other way to know. It is more work than a feedback button, and it is also the only reason I can publish a number like this recovered 34.5% of the lost edge definition across seven test clips — and on the seventh, a dark fine-grained forest scene, it went backwards. Measuring your own product properly means occasionally publishing that it loses. Users notice; it is the cheapest credibility available to a site with no domain authority.

If you want to see what the shape looks like in practice, the upscaler I built this way is the worked example — free, no account, nothing uploaded, and every capability claim on it traces to a measured run.

It is a positioning decision, not a technical one

The temptation is to treat client-side compute as an optimisation: same product, cheaper to run. It is not. It changes what you can promise, who you can serve, and what you are able to learn about your own users — all three at once, and not all three in your favour.

For a tool where people hand over personal files and get them straight back, the trade is excellent: you give up analytics and a device-share of your market, and in exchange you get the only privacy claim in your category that a sceptical user can verify without trusting you. For a product built on aggregation, network effects, or a proprietary backend, the same trade is a bad one.

Work out which of those you are before you write a line of shader code. If you are curious about the mechanics of the first kind, I wrote up how the pipeline fits together — decode, GPU pass, re-encode, all inside the tab.