A browser-only tool doesn't have to forget your work

Two different promises share one label

A tool can promise two different things, and “browser-only” is usually used to mean only the first: that nothing typed into it is ever sent to a server, the privacy claim this blog has already covered as the one worth actually checking in a browser's own network panel. The second promise — that the tool remembers nothing about what was typed in once the tab closes — is a separate design decision, not a consequence of the first. A tool can keep every answer entirely on the visitor's own machine, written only to that visitor's own browser, and still recall it perfectly the next time that same visitor opens the same page. Nothing about never sending data anywhere requires throwing it away locally too.

What gets lost when the two get conflated

A long classification questionnaire or a multi-field cross-border tracker entry represents real work — a dozen questions answered, a technical rationale typed out, a set of citations checked one at a time. A tool that treats “browser-only” as license to hold none of that past a page refresh asks a visitor to redo all of it if a laptop sleeps, a tab gets closed by habit, or a flaky connection reloads the page mid-session — even though no network request was ever actually at risk, because none was ever sent. That's a cost the privacy promise never asked for. It's a side effect of writing the simplest possible stateless page and calling the simplicity a feature.

Local storage keeps the promise and the work

A browser's own storage — localStorage, sessionStorage, IndexedDB — lets a tool hold a visitor's in-progress answers on that visitor's own device, readable only by that visitor's own browser, with nothing about the privacy claim weakened by using it. A classification tool that writes each answer to local storage as it's typed, and reads it back if the same visitor returns to the same page, has lost nothing a server-side save would have offered and given up nothing the no-network-request promise depends on. The one honest caveat belongs in the tool's own text, not a settings menu nobody opens: this browser, this device, for as long as this browser's storage isn't cleared — not a synced account, not a backup, not a guarantee against a wiped cache or a private window.

The warning a tool owes before the harder case

Not every tool should hold its own state quietly forever — a document generator that assembles a tracker from scores of answers is a reasonable case for asking, in plain language before the first field, whether the visitor wants their answers remembered on this device at all, rather than deciding it for them. And for the case local storage doesn't cover — a visitor who wants the same half-finished answers back on a different device, or after clearing their own browser data on purpose — the honest answer is that a purely browser-only tool can't do that without exporting a file the visitor keeps themselves, not a login this shelf has no reason to ask for. A tool that stays quiet about which of those two situations it's actually in repeats the same failure this blog has already traced in the privacy claim itself: a promise nobody can check is not much of a promise.

Where this meets the file

The interactive tools previewed under the launch catalog's own tools section are built to hold in-progress answers in the visitor's own browser storage rather than discarding them on refresh, with that choice disclosed in the tool's own text rather than assumed silently either way. That's a second design rule sitting next to the no-network-request promise this shelf already holds itself to, not a substitute for it. If a tool here ever gets that balance wrong — forgetting work it should have kept, or keeping something a visitor would rather it hadn't — the shelf takes that correction directly.