Browser-Only Tools: How to Check a Website Isn't Uploading Your Files

You need to merge two PDFs. One is a signed rental contract, the other is a scan of your passport. You search "merge pdf", click the first result, drag both files in, and get a merged file back a few seconds later. Quick and free, and both documents now sit on a server you know nothing about.

That's how most online file tools work: your browser uploads the file, a server processes it, and you download the result. Whatever the privacy policy says, the file has left your machine. How long it stays on that server, who can read it there, and whether it ends up in backups or logs is not something you can check.

There's another way to build these tools, and you can check for yourself which kind you're using.

What "browser-only" actually means

Modern browsers can do far more than show pages. A web page can read a file you pick, using the File API, without sending it anywhere. It can then process that file in JavaScript or WebAssembly. It can draw and re-encode images on a <canvas>, compute hashes and verify signatures with the Web Crypto API, and hand you the result as a download made from memory.

A tool built this way sends you the program (HTML, JavaScript, sometimes a WebAssembly module) once, and then your device does all the work. The file you drop in never travels over the network, because there is no server-side code waiting to receive it.

Every tool on Dimas' Toolbox processes your input this way. A few also need to fetch something from the network to do their job, and they're listed below. The PDF tools use pdf-lib and Mozilla's pdf.js, loaded from this site. The image tools use the browser's own canvas. The crypto tools use Web Crypto, which is built into the browser.

Why it matters for specific kinds of data

"Privacy" can sound abstract, so here's what each kind of file actually carries.

PDFs: contracts, payslips, IDs, medical letters

The PDFs people most often need to merge, split, or shrink are exactly the ones they least want to hand out: tenancy agreements, bank statements, scanned IDs, invoices with addresses and account numbers. A browser-only tool such as PDF Merge & Organize or the PDF Compressor gives you the same result as an upload service without the copy on someone else's disk.

PDFs also carry metadata you may not know about: author name, the software that created the file, and creation and modification dates. Before you send a document, open it in the PDF Metadata Viewer to see what it says about you. The PDF Compressor removes unnecessary metadata as part of shrinking the file.

Photos: location, device, time

Photos from a phone often contain EXIF data: camera make and model, the date and time the photo was taken, and on many phones the GPS coordinates of where it was taken. Uploading a photo to a random converter hands all of that over along with the pixels.

The Image Metadata Viewer shows the camera make, model, date taken, orientation, and software stored in a JPEG. Tools that re-encode an image through a canvas, such as the Image Compressor, write a new file that holds only pixels, so the original EXIF block isn't copied into the result. That's a side effect, not a guarantee for every tool, so check the output in the metadata viewer if it matters. iPhone photos in HEIC format can be turned into regular JPGs with the HEIC to JPG Converter without leaving your device.

JWTs and API tokens: live credentials

A JSON Web Token is a credential. If the token in your clipboard is still valid, whoever holds it can act as you until it expires. Pasting a production token into a decoder that sends it to a server is the same as pasting your session cookie into a stranger's form.

The JWT Decoder splits and decodes the token locally. It can also verify the signature with your secret or public key, using Web Crypto, so the key stays in the browser too. If you're debugging a token problem, the JWT debugging walkthrough covers the full process.

Passwords: the obvious one

You would never type your real password into a website just to "check its strength"... unless the check happens on your own device. The Password Strength Checker estimates entropy and crack time locally and never sends the password anywhere. The Password Generator draws its randomness from crypto.getRandomValues, the browser's cryptographically secure random number generator, not Math.random. The Hash Generator computes SHA-256 and related hashes with Web Crypto, so even a hash of a secret is never computed on someone else's machine.

How to verify it yourself

You don't have to trust anyone's claim, including this one. Any desktop browser lets you watch exactly what a page sends. This takes about five minutes the first time.

1. Open the tool page, but don't load your file yet.
2. Open DevTools: press F12, or Cmd+Option+I on a Mac. Switch to the Network tab.
3. Turn on "Preserve log" (in Firefox, "Persist Logs" in the settings menu) and click the clear button (🚫) to empty the list. Now only requests made from this point on will show up.
4. Use the tool with a test file of a recognizable size, say a 4 MB PDF. Merge, compress, convert: whatever the tool does.
5. Look at the requests that appeared. Sort by method or look for POST and PUT requests. An upload shows up as a request whose body is roughly the size of your file. Click a request and check the Payload (Chrome) or Request (Firefox) tab to see what was sent. Also check the WS filter: a tool could stream data over a WebSocket instead of a regular request.
6. Try it offline. Reload the page so everything is loaded, then go offline: in DevTools' throttling dropdown choose Offline, or turn off Wi-Fi. Run the tool again. If it still produces a result, the processing is happening on your device. A server-side tool will fail or hang.

The offline test is the quickest signal, and the Network tab is the proof. Together they take less time than reading a privacy policy, and they tell you more.

What you'll see on this site

If you run this check on Dimas' Toolbox, the list won't be empty, and it's worth knowing what's there:

• Page assets: JavaScript chunks, fonts, and for PDF tools the pdf.js worker, all loaded from dimastoolbox.com. These are downloads to your browser, not uploads.
• Google Analytics: small requests to google-analytics.com when the page loads and when you use a tool. They record the tool and a short action name, like "compress" or "copy". They don't include your file, its name, or what you typed. Each one is a few hundred bytes, which you can confirm in the Payload tab.
• Vercel Speed Insights: page-performance measurements such as load time.

None of them is anywhere near the size of a 4 MB PDF, and none carries file content. That's the point of the check: you don't have to take this paragraph's word for it.

The exceptions, stated plainly

A few tools need to fetch something from a third party, and the offline test will catch them:

• The DNS Lookup tool sends the domain name you enter to Cloudflare's public DNS-over-HTTPS service. A DNS lookup is a question to the network, so there's no way around it, and the tool says so on its page.
• The Background Remover downloads its AI model (about 26 MB) from Hugging Face on first use. The photo itself stays in the browser tab, and the model runs on your device.
• Font tools such as the Font Pairing Generator load the fonts you preview from Google Fonts, which tells Google the font names.

Those are downloads, not uploads, but the third party sees a request from your IP address. The Network tab shows exactly which request goes where.

What browser-only doesn't protect you from

Running locally removes the biggest risk, a copy of your file on someone else's server. It doesn't make your device a vault. A few honest limits:

• You still run the site's code. A page that processes files locally today could ship different code tomorrow. The Network-tab check verifies the version you're looking at, not every future version. For anything truly sensitive, run the check each time, or do the offline test first.
• Browser extensions can read pages. An extension with "read and change all your data on all websites" permission can see whatever a page shows, including a decoded token. Use a private window with extensions disabled for the sensitive stuff.
• The output lands on your disk. A merged contract in your Downloads folder is only as private as that folder. Delete what you don't need, especially on a shared computer.
• Metadata can survive. Merging or converting doesn't necessarily remove author names or EXIF data. Check the result with the PDF Metadata Viewer or Image Metadata Viewer when it matters.

A short checklist before you drop a file in

• Does the page say the tool runs in the browser? Treat that as a claim to check, not a fact.
• Does it still work offline after the page has loaded?
• During use, does the Network tab show any request close to your file's size?
• For credentials (tokens, passwords, keys): would you be comfortable if this exact string ended up in a log file? If not, only use a tool that passes the first three checks.

Where to go from here

The browser-only tools for the file types above are grouped by category: PDF & document tools, image tools, developer tools for tokens, encoding, and hashing, and generators for passwords and random data. If you'd rather scan everything at once, the full directory of all tools lists every tool on the site, grouped by category. Pick any of them and run the DevTools check from this post.