Guide — trust

Tools that never phone home

Why the best small web tools run entirely in your browser, what that can honestly cover in 2026, and how to verify any tool's privacy claim in about a minute.

Written by the maker of these tools Updated 2026-08-18 7 min read

The short version: a web page can resize your images, strip your metadata, check your passwords and convert your files without sending a single byte anywhere, because the browser itself is a capable computer. When a tool does upload your file instead, you are trusting someone's retention policy. When it doesn't, you are trusting physics. You can tell the two apart with the network tab.

What "runs in your browser" actually means

Every web tool is a program. The only question is where it runs. A local-first tool ships its program to your browser and does the work on your device: your file is opened by your own machine, transformed in your machine's memory, and saved back to your disk. The page you loaded is just the workshop the job happens in.

An upload-based tool does the opposite: your file travels to the operator's server, the work happens there, and a result travels back. Both approaches produce the same resized image. They differ in one thing only, and it is the thing that matters: custody.

What you give away when a tool uploads

The moment a file leaves your device, three guarantees quietly become promises. Whether the file is deleted after processing is a policy. Whether it was logged, cached or backed up along the way is an implementation detail you cannot see. Whether the operator, their hosting provider or a future buyer of the company treats it the same way next year is unknowable. None of this requires bad intent; it is simply what handing custody over means.

For a holiday photo, that trade may be fine. For a passport scan, a contract, a medical document or a photo whose EXIF still carries your home coordinates, "we delete uploads after one hour" is a sentence on a website, not a property of the system. A tool that never receives the file cannot mishandle it. The best data protection is not having the data.

What a browser can genuinely do in 2026

The upload model made sense when browsers were thin. They have not been thin for a decade. Standard, well-documented APIs now cover most of what everyday utility sites sell:

Files stay local by default: a file you "choose" is read by the page's own code via the File API; nothing about picking it transmits it anywhere.
Images decode, scale, recompress and re-encode on a canvas. Resizing, compressing, format conversion and pixel sampling are all local canvas work.
Bytes can be parsed directly. Our EXIF remover walks the JPEG's own segment structure in an ArrayBuffer and writes a clean copy, byte for byte, without ever decoding the picture.
Cryptographic randomness comes from the device itself via the Web Crypto API, which is why a password generated here never exists anywhere else.
Time zone math ships with the browser: the Intl API carries the full IANA time zone database, current DST rules included.
Heavy work can leave the main thread. Our regex tester runs patterns in a worker so a pathological one can be killed instead of freezing your tab.

Everything in that list is standards-track platform capability, not a trick. The machine you are reading this on is more powerful than the servers most of these jobs used to run on.

The honest limits

Local-first is a discipline, not a religion, and it has real edges. A browser cannot fetch live exchange rates without asking a server for them. It cannot check whether someone else's link is dead, because cross-origin rules rightly stop pages from probing arbitrary sites. It cannot send email or look up today's weather from nothing. Some jobs are also simply better done with big shared infrastructure.

The discipline is drawing the line honestly. We killed a currency converter rather than ship one with silently rotting baked-in rates, and the sites in this network that do need live data, like routing or weather, say so on their own pages instead of pretending otherwise. "Everything runs locally" is a per-tool claim that must be true per tool, never a slogan.

How to check any tool in one minute

You do not have to trust any of this, which is the point. The browser will tell you what a page does:

Open the tool, press F12, and switch to the Network tab.
Clear the log, then use the tool: load your file, run the conversion, download the result.
Watch what appears. A local-first tool shows no new requests while you work, and above all nothing the size of your file leaving. An upload tool shows a POST the moment you drop the file in.

A site can go one step further and make one whole class of misbehavior technically impossible: a Content-Security-Policy header can instruct your browser to block the page from contacting any other domain at all. That turns "we don't send your data anywhere" from a promise into a rule your own browser enforces. Few tool sites ship one. Ours is printed on the privacy page, next to a live counter your browser fills in itself.

How plainforge holds itself to this

plainforge is a workshop of 43 small tools built on exactly this model: static pages, no accounts, no analytics, zero requests to other domains, one accountable maker with a public imprint. The claim is enforced by the CSP described above and checkable with the network-tab drill on every page. Where a job cannot be done locally to a standard worth shipping, the tool does not exist here. That rule has cost us tools, and it is the reason the rest can be trusted.

See it in practice: open any bench in the tool directory with the network tab up. The EXIF remover is a good first test, because you can watch a photo get cleaned while nothing leaves.

Open EXIF Remover

Fair questions

If the page loads from a server, can't it just upload my file anyway?

A malicious page could try, which is why the verification drill checks behavior, not claims. On this site the CSP additionally instructs your browser to refuse any request to another domain; the network-tab check covers the rest. Watch it once; after that you know how the page behaves.

Is local processing worse quality than server processing?

For the everyday jobs covered here, no. The browser uses the same class of codecs and math a server would. Differences show up in specialist work: massive video transcodes or jobs needing shared data are still server territory, and honest sites say so.

Does local-first mean the site can't make money?

It rules out the usual way, which is selling attention and data. It leaves the honest ways: clearly labelled sponsorship, or simply being the reason people trust the rest of your work. This site runs on the latter while the sponsor slots stay open.

The working rules

Sensitive file plus upload-based tool: don't. Find a local one.
Any tool, any site: run the one-minute network-tab check before you trust it with something that matters.
Prefer tools that publish a restrictive Content-Security-Policy; it is the difference between policy and physics.
Treat "we delete your files" as marketing until the file never leaves your machine in the first place.

Written at the forge. This guide is by Justas Jarmalavičius, the independent maker of plainforge's 43 browser-local tools and the 34-site network around them. Guides here exist only where the workshop has real standing: we describe mechanisms we have implemented ourselves, and every claim is checked before it ships.

Sources and further reading

MDN: File API — how pages read local files without transmitting them.
MDN: Canvas API — on-device image decoding, scaling and encoding.
MDN: crypto.getRandomValues() — cryptographically strong randomness in the browser.
MDN: Content Security Policy — how a page can be blocked from contacting other origins.
IANA time zone database — the zone data browsers ship via the Intl API.