Home › How it works, and how to check it yourself

How it works, and how to check it yourself

Any site can claim your file stays on your device. Here is a way to confirm it in about thirty seconds.

The short version

Every page on this site is a single HTML document plus one JavaScript file. That script contains the actual algorithm implementations — MD5, SHA-256, Base64, the CSV parser, the JSON-to-YAML writer, the PDF assembler. When you drop a file or type text, the script runs in your tab and produces the result. There is no API endpoint to send anything to.

How to verify it

Open any tool — the SHA-256 generator is a good one because you can compare its output against a known value.
Open your browser's developer tools with F12 and switch to the Network tab. Clear it.
Type or paste something into the tool and watch the network panel. You will see no request carrying your input — no fetch, no XHR, no form submission.
Now disconnect from the internet entirely and use the tool again. It behaves identically, because it never needed the network.
For an image tool, drop a large photo and watch the same panel. The file is read through the browser's file API, not uploaded.

Step 4 is the one that settles it. A site that uploads your file cannot possibly work with the network disconnected — and this one does.

What 'browser-only' cannot do

Being honest about the limits is more useful than another paragraph of reassurance. Processing inside a browser is not the same as running a tuned server-side pipeline, and there are things this approach genuinely cannot match:

No OCR. A PDF assembled from photographs is a stack of images with no text layer. Making it searchable requires optical character recognition, which is a server-scale job.
No magic compression. The encoders available are the ones your browser exposes. A server running mozjpeg or libavif can shave off a further percentage that this site cannot.
No multi-file pipelines. Merging existing PDFs, splitting pages or rotating a document needs a PDF parser, which is a much larger piece of software than the writer used here.
Bounded by your machine. A multi-gigabyte operation is limited by your tab's memory, where a server would stream it.
No batch queue. Files are processed one at a time in the tab, in the order the codec can keep up.

Where those limits bite — OCR and PDF merging in particular — a server-side tool is the right answer, and you should use one. Privacy and capability are a genuine trade-off, not a free lunch.

Why build it this way at all

Two reasons. The first is that most of these jobs do not need a server: hashing a string, converting a JSON document or resizing a photograph are all comfortably within a browser's reach, and adding a server adds a place for your data to leak without adding anything you wanted. The second is that the alternative has become the default so completely that people no longer notice it — the upload box is simply assumed, and with it the assumption that handing over a copy is the price of getting the job done.

Accuracy of the written material

The explanations on each tool page cite the governing standards where one exists — RFC 4180 for CSV quoting, RFC 4648 for Base64 and its URL-safe alphabet, RFC 2104 for HMAC, FIPS 180-4 for the SHA-2 family, RFC 8259 for JSON, RFC 3986 for percent-encoding. Where specific numbers are given, such as the 300 dpi pixel counts for passport photographs or the collision timeline of MD5 and SHA-1, they are stated with their source or their date so you can check them independently.