How to Actually Verify a Tool Is Private: The 2026 Field Guide

A few months ago I was helping a friend who runs a small legal practice compress a batch of client PDFs. She'd Googled "compress PDF online free," picked the top result, and was about to feed twelve years of privileged correspondence into a website whose privacy policy she had not read. The tool's landing page said, in a reassuring green bar at the top: "100% private. Files never leave your device."

I asked her to open her browser's DevTools before she clicked the upload button. The Network tab lit up like a Christmas tree. Every single PDF was being POSTed to an S3 bucket in us-east-1 before the tool did anything to it. The "never leaves your device" claim was, to put it charitably, aspirational.

That's when I realised most people have no idea how to check. "Private" has become a word that means whatever the marketing team wants it to mean, and the burden of verification has quietly shifted to the user. So this piece is the field guide I wish I'd handed my friend. Four checks, none of which require being technical. By the end you'll be able to tell — in under two minutes — whether a tool is doing what it says.

'Private' has become a marketing word

Walk through any of the big online-tools categories — PDF converters, image compressors, video trimmers, resume builders — and count how many landing pages use the word "private" in the hero. It's genuinely most of them. The word costs nothing to slap on a page, and it converts. People want their files to stay theirs. Companies have learned to say the magic words.

The problem is that "private" has no legal or technical definition in this context. It's not like "organic" (which has a USDA certification behind it) or "HTTPS" (which you can verify with a padlock icon). A tool can call itself private while doing any of the following: uploading your file to a server, keeping a copy for 24 hours "for processing," logging metadata, running OCR on your document and feeding the text into a training set, or selling anonymised derivatives to data brokers. All of that is legal in most jurisdictions as long as it's disclosed somewhere in the terms.

In 2026 the situation has actually gotten worse, not better. The rush to feed large models on real-world documents has turned every "free" tool that touches your files into a potential training-data pipeline. If you can't explain how a free tool makes money, you should assume the answer involves your data.

The five things a truly private tool does not do

Before we get to the checks, here's the reference sheet. A tool that is genuinely private — the kind that could be audited by a privacy lawyer without anyone reaching for the antacids — does not do any of these five things:

1. It does not POST your file to a server. No upload endpoint. The bytes stay in your browser's memory.
2. It does not require you to sign in to use the core feature. Auth walls exist to build a user record. If the tool works without them, it should offer that path.
3. It does not claim rights over your content. Read the terms; look for the words "license," "royalty-free," and "worldwide." Any of those near "your content" is a red flag.
4. It does not embed third-party trackers that see your file names. Facebook Pixel, Hotjar, session-replay tools — they can, and often do, record what you typed and what you dragged in.
5. It does not obscure how it works. A private tool is usually proud of being private. If the "how it works" page is missing or written in marketing fog, that's an answer.

Now let's verify. Four checks, in order of effort. Do #1 for every tool; do the rest if #1 raises a flag or if the file is sensitive enough to matter.

Check #1: open DevTools — Network tab (60 seconds)

This is the single most useful check, and no one does it. Here's the whole recipe:

1. Load the tool's page in Chrome, Firefox, Edge, or Safari.
2. Press F12 (or right-click anywhere → Inspect).
3. Click the Network tab in the panel that opens.
4. Tick Preserve log if you see it, then click the little 🚫 icon to clear.
5. Use the tool. Drop your file in. Click the button. Do the thing.
6. Watch the request list.

What you're looking for: any row with a POST or PUT method, especially one whose size roughly matches your file. Click that row. Look at the Request Payload or Payload tab. If your file's content is sitting there — as raw bytes, as base64, as multipart form data — then your file just left your device. The privacy claim on the landing page is a lie or, at best, an interpretation.

What's OK to see: static asset loads (JS bundles, CSS, fonts, images from the tool's own CDN), small analytics beacons (a few hundred bytes to Google Analytics, Plausible, PostHog), and — the important one — WebAssembly modules loading. WASM files can be several megabytes and look scary in the Network tab, but they're the tool arriving in your browser, not your file leaving. Learn the direction.

Check #2: look for the file-upload endpoint in the source

This one takes another minute and confirms what the Network tab suggested. Every tool that uploads files has to have, somewhere in its JavaScript, a call to either fetch(), XMLHttpRequest, or an SDK method that wraps one of those. You can find it without knowing how to code.

In DevTools, switch to the Sources tab (Chrome/Edge) or Debugger tab (Firefox). Use Ctrl+Shift+F (Windows/Linux) or Cmd+Option+F (Mac) to search across all loaded scripts. Search for these strings, one by one:

• FormData — the standard way to POST a file
• multipart/form-data — the MIME type for file uploads
• /upload, /api/convert, /process — common endpoint names
• s3.amazonaws.com, storage.googleapis.com, blob.core.windows.net — cloud storage domains

If none of those turn up, the tool almost certainly isn't uploading. If any of them do, click through to see the surrounding code. You don't need to understand the JavaScript — you're just checking whether there's an obvious file-shipping path. Modern tools are compiled and minified, so the code will look ugly, but the string matches are still meaningful.

Bonus signal: a truly client-side tool often loads a big WebAssembly binary or a large JavaScript bundle (5MB+) because the whole processing library — libpdf, libwebp, ffmpeg.wasm — has to come to your browser. A server-side tool tends to be a lightweight page (200-500KB) because all the heavy lifting happens elsewhere. Look at the total transferred at the bottom of the Network tab. Small page + big file processing = the file is going somewhere.

Check #3: read the actual privacy policy for the four escape words

Most privacy policies are boilerplate. Nobody reads them, so the incentives to write clear ones are weak. But there are four words that, if you find them, change the meaning of the whole document. I call them the escape words because they're the legal hatches through which any earlier privacy claim can quietly leave the building.

1. "Perpetual." If a tool grants itself a "perpetual" license to your content, that license doesn't end when you close the tab or delete your account. Whatever they've got, they keep.

2. "Sublicensable." This means they can hand your content to third parties without asking. Data brokers love this word. So do AI training partnerships.

3. "Derivative works." This gives them the right to make new things from your content — including, in 2026's very expansive interpretation, model weights trained on it. If a policy grants rights to make derivatives, the content is training data.

4. "Improve our services." The most innocuous-sounding of the four, and the one that does the most damage. "We may use your content to improve our services" is the legal underpinning for reading, indexing, and training on your files, all while the marketing team says the tool is private.

Cmd/Ctrl+F the privacy policy for those four terms. If you find any of them attached to your uploaded content, the earlier privacy claim on the homepage is legal fiction. A genuinely private tool doesn't need these clauses because it never received your content in the first place.

Check #4: turn off Wi-Fi and try again

This one is my favourite because it's beautifully binary. Load the tool's page with a working connection. Then switch off your Wi-Fi (or hit airplane mode). Try to use the tool.

If it works — if you can drop a file in, hit convert, and get a result while fully disconnected from the internet — then the tool is running entirely in your browser. There's no way for it to be talking to a server it can't reach. This is the strongest possible confirmation of client-side processing, and it takes about ten seconds.

If it fails, error-messages, spins forever, or shows a "network error" toast, then the tool needs a server. That doesn't automatically mean it's evil — some operations genuinely can't run in a browser, and we'll talk about the honest cases in a second — but it means the "your file never leaves your device" marketing is false. Full stop.

One caveat: some tools cache aggressively via service workers and will appear to work offline the first time you disconnect, because the JavaScript and page assets are cached, but they'll fail on the actual conversion step. Watch for that. The real test is whether the processing completes offline, not whether the page renders.

When a tool DOES need to upload — the honest cases

I don't want to leave you with the impression that all server-side tools are malicious. There are legitimate reasons a tool has to talk to a server, and it's worth naming them so you know when to be suspicious and when to be reasonable.

OCR at scale. Running Tesseract in a browser works for a page or two but chokes on a 200-page scanned book. Server-side OCR with GPU acceleration is genuinely faster. If you're OCR'ing something sensitive, though, look for tools that run Tesseract.js locally — they exist, they're slower, and they're worth the wait.

AI-heavy features. Anything that involves a large language model, image segmentation, or diffusion — background remover, upscaler, "magic edit" — realistically has to run on a GPU somewhere. Nobody has a 40GB model sitting in their browser. The question isn't whether these tools upload; it's what happens to the file afterward.

Collaboration features. If two people need to edit the same document in real time, there has to be a server holding the source of truth. Google Docs isn't privacy-oriented for this reason, but that's a fair trade — you knew you were sharing.

Cross-device sync. Same story. If you want to start a task on your phone and finish it on your laptop, the file has to be somewhere both can reach. That's a legitimate cloud, not a privacy failure — as long as it's encrypted properly and the provider can't read it.

The pattern to want, if a tool must upload: end-to-end encryption with client-held keys. The provider stores the encrypted blob but can't decrypt it. Signal-style, Cryptomator-style, Proton-style. If a tool describes its architecture this way with actual specifics — not just "we use encryption" — you're probably safe.

How Toolspace scores on its own checklist

Fair play requires that I run this checklist on my own site. I'd be pretty miserable if you did the audit and I hadn't. So here's Toolspace against its own four checks, honestly.

DevTools Network check. Open the BMI calculator or the age calculator with the Network tab open. Type numbers, click through. You'll see the initial page load and some analytics beacons; you will not see anything being POSTed back with your inputs. The calculators are pure JavaScript running on your machine.

Source check. Search across the loaded scripts for FormData or /upload. For the calculators and most of the utility tools, they don't appear. For our PDF tools, we load pdf-lib and PDF.js directly in the browser — bulky WASM/JS payload, no upload endpoint. The whole point is that we chose the slower-to-load, no-servers path deliberately.

Privacy policy escape-words check. Grep our policy for "perpetual," "sublicensable," "derivative works," "improve our services." We don't claim any of those rights over your inputs, because we don't receive your inputs in the first place. Our policy is short for that reason — there's not much to say about data we never got.

Airplane-mode check. Load the site, disable Wi-Fi, use any of our calculators or PDF tools. They keep working. This is the check that made me build Toolspace the way I did: I wanted every single tool on the site to pass the airplane test, and every tool that ships here has to pass it before it goes live.

None of that makes Toolspace uniquely virtuous. It makes it verifiable. That's the standard I think we should hold the whole category to. Not trust. Not vibes. Verifiability. Browse the full tools directory and try the checks yourself. If any of them fail, tell me — that's a bug worth fixing, publicly.

FAQ

Related tools & reading

• Browse all Toolspace tools
• Browser-native PDF tools
• BMI Calculator (fully client-side)
• Age Calculator (nothing leaves your browser)
• More on the Toolspace blog

Nothing on this page is legal advice. If you're handling data that's regulated under GDPR, HIPAA, or a similar framework, the checks above are a starting point, not a compliance audit — talk to a privacy lawyer or DPO who can review the specific tools against your specific obligations.