22 tools that run entirely in your browser: what that decision costs and buys

Show & TellDaisy3 replies

DaisyRegular#1

There are 22 tools under /tools that run completely in your browser. Nothing is uploaded, nothing is sent to a model, no account is needed. That was a product decision with costs as well as benefits, and this is what the trade looked like.

What it buys

The input never leaves the machine. For the tools that touch sensitive things — a background remover for customer photos, a PII redactor, an X.509 certificate decoder, a bcrypt or RSA key generator — this is the whole point. There is no "we do not store it" policy to read, because there is no server in the path.

It works offline, and it works on a locked-down network. No API key, no rate limit, no queue. A tool that runs in the page works in an air-gapped environment, which is where half of these are actually used.

It is free in the only sense that matters. No API bill, no per-run cost, no account. The price of a run is your electricity.

What it costs

Big models do not fit in a browser. The background remover ships a small model through transformers.js, about 6.6 MB in the q8 build, because the stronger candidates were ruled out on licence grounds or on size. A model in the page is a download, and the download is the latency.

The heavy tools are impossible. Anything that needs a server GPU — a full PDF parser with layout analysis, a video converter, an embedding model over a large corpus — cannot be done this way. The tool catalogue is split along that line, and the line is not negotiable.

The browser is a hostile place for a library. 22 tools means 22 bundles, and every one of them is a dependency with its own supply chain, running in the same origin as the page. The work is in keeping them small and in not pulling a general-purpose framework into a tool that needs a text area.

Debugging is the developer's problem. A tool that fails in a browser gives you a stack trace in a console the user does not have open. The error messages have to be written for the person looking at the screen, not for a log file.

The rule we ended up with

If the whole task fits in a browser tab — text, images, small files, local computation — it runs in the browser. If it needs a server, it is a different product with different rules, and the ones under /tools that cost points are the ones that call a model.

3 replies

JimmyMember#2

The licence point deserves repeating, because it is the reason the background remover ships the model it does.

The stronger matting models are either non-commercial in their weights or large enough that a one-off cut-out would spend more time downloading than doing. A model you cannot ship is not a model, whatever the benchmark says.

IvanMember#3

In reply to Jimmy (#2)

The failure-message point is the real cost and it is under-appreciated. A server-side tool can log the stack trace and show a useful error. A browser tool has to catch the error itself, decide what is worth showing, and format it for a screen with no console open.

That is a lot of work per tool, and it is the reason the "report this" button exists on the ones that fail often.

DaisyAuthorRegular#4

In reply to Ivan (#3)

Both are right, and the licence rule is the one I would put at the top of the list, because it decides what is possible before you write any code.

The order we actually use: can the licence of the model and the weights be shipped? Can the whole thing run in a tab? Only then do we look at what it costs. The third question is what makes the rest of the catalogue the way it is.