Do 'free' PDF tools really upload your files? The 30-second test anyone can run

You've done it. I've done it. There's a PDF that's too fat to email, or three files that need to be one, so you type "merge pdf" into Google, click whatever's at the top, drag your file in, and ten seconds later you've forgotten the whole thing happened.

The result downloads. It works. You move on.

But where did that file go for those ten seconds? Did it sit on your laptop the whole time, or did it quietly take a round trip to a server in a country you couldn't point to on a map, run by a company you've never heard of, under a privacy policy you obviously didn't read?

I'm not here to make you paranoid. I'm here to show you how to check, in about thirty seconds, using a tool that's already sitting on your computer. The wild part isn't that some of these sites upload your files. It's that you can watch it happen live, and once you've seen it, you genuinely can't go back to not knowing.

First, what "free online tool" actually means under the hood

There are basically two ways a website can deal with your PDF, and they could not be more different in what they do with it.

The first is server-side. You drag your file in, your browser quietly ships it off to the company's computers, the work happens over there (merging, compressing, converting, whatever), and then you download the finished thing back. Many of the big-name free tools run this way. It isn't sinister. It's just the easy way to build a tool: let a server you control do the heavy lifting.

The second is client-side, or browser-only. The page loads, but the actual work happens on your machine, in JavaScript and WebAssembly. The file doesn't travel anywhere. Your laptop does the job, the way a desktop app would.

From where you're sitting, these two are indistinguishable. Same drag-and-drop box. Same little spinner. Same download button at the end. You cannot tell them apart by looking, and the marketing won't save you, because "free," "fast," and "secure" get stamped on both kinds. That last word is the sneaky one. "Secure" usually just means they bothered to use HTTPS, which protects your file while it's flying to their server and tells you exactly nothing about what happens after it lands.

So you stop reading the copy and you start watching the traffic.

The 30-second test

Every modern browser ships with a developer panel, and one tab inside it logs every single thing your browser sends and receives. It doesn't care what the website claims. It reports what actually happened. Think of it as a flight recorder bolted to your file.

Here's the whole ritual.

1. Open the Network tab. On the tool's page, right-click anywhere and pick "Inspect," or just hit F12 (Cmd + Option + I on a Mac). A panel pops open. Click the tab labelled Network. If it looks empty, good. It only records while it's open.

2. Tick two boxes. Up near the top of that panel, check Preserve log (so the record survives a page reload) and Disable cache (so nothing gets served from memory and muddies the result). Two clicks now, and you save yourself the later moment where you're convinced the test is broken when it's quietly working fine.

3. Do the thing you came to do. Drag your PDF in. Hit merge, or compress, or whatever the button says. Watch the rows pile up.

4. Read the verdict. Keep an eye on the Size and Time columns while your file gets processed. The tell is hard to miss:

• A tool that uploads your file will fire off a request the instant you hit go, and its size will roughly match your file. A 12 MB PDF makes a request that's, shocker, around 12 MB heading out. There's a pause while it travels, then the answer comes back. That fat outbound row is your document leaving the building.
• A browser-only tool does almost nothing in that list when you hit "merge." No big outbound request, no upload bar, no waiting on some machine three time zones away. The file appears, the work's done, and the Network tab stays dead boring. Boring is the whole point.

One honest footnote, because I'd rather you trust me than be impressed by me: when a big file goes up as a form upload, the browser sometimes won't let you crack open the request and read the raw bytes. People who want to argue with this test love to point at that and say "see, you can't actually prove anything." You don't need the bytes. You can still see the request exist. You can see its size. You can see how long it took to send. A multi-megabyte outbound request that shows up the very second you click "merge" is not a mystery. The file went. The body being hidden is a display quirk, not a clever hiding spot.

The even lazier test (zero DevTools)

Don't fancy opening a developer panel? There's a blunter version that works embarrassingly well.

Load the tool's page once with your internet on, so the whole page downloads. Then kill your Wi-Fi. Now try to use it.

A browser-only tool just keeps going. It already has everything it needs, the processing runs on your machine, and it couldn't care less that you're offline. A server-side tool falls over instantly, because it has nowhere to send your file. The spinner spins into eternity, or you get an error.

It's the privacy version of yanking the lamp's plug to find out whether it was ever plugged in. Crude, sure. But it doesn't lie. If a tool that swears it "never leaves your device" drops dead the second you pull the cord, that promise was decoration.

Hold on, is uploading automatically a bad thing?

No. And I want to be fair, because the scaremongering version of this article is the lazy one.

Plenty of server-side tools are run by careful people who delete your file an hour later, encrypt it on the way up, and never glance at it. Uploading isn't theft. It's a design decision with strings attached.

The catch is that you're being asked to take all of it on faith. Once your file lands on someone else's server, your privacy rides entirely on stuff you can't see and can't check: how long they keep it, whether they've been breached, who their subcontractors are, which country's courts they answer to, and whether some future tweak to the terms quietly hands them permission to train on your documents. You're trusting a stranger's housekeeping, sight unseen.

And the things people actually feed these tools are rarely a lunch menu. It's bank statements. Tax forms. A scanned passport. A signed contract. A kid's birth certificate for some school form. The precise documents you'd never email to a stranger, casually handed to one, because the box said "free" and "secure" and you were running late.

The simplest way to stop worrying about a server's data policy is for your file to never reach a server. You can't leak what you never sent.

The setup that makes the test come up empty

I'll come clean: I build one of these tools, pdfandimagetools.com, and the only reason I'm comfortable writing all this is that I want you to run the test on it. The entire design goal is that the Network tab comes up empty.

There's no magic. It's just a question of where the code runs. Browsers got seriously capable over the last few years. WebAssembly lets real, compiled processing libraries run inside the page at close to native speed, and the same machinery that powers in-browser AI can run a background-removal model on your own hardware without phoning home. So merging, compressing, splitting, converting, even pulling text out of a scanned page, all of it happens right there in the tab. The server's one and only job is to hand you the webpage. After that, it's just you and your laptop.

There's a perk nobody bothers to mention: it's often faster. You're not shoving a 40 MB file up your home Wi-Fi and waiting to drag it back down. The round trip simply isn't there. And because the work lives in the page, it keeps running with the Wi-Fi off, which, yes, means it passes the lazy test too. Please try to break it.

I'll be straight about the limits too, because a tool that claims to be flawless is its own red flag. Doing everything in the browser means your device's memory is the ceiling, so a huge batch on an old phone can run out of room where a beefy server wouldn't even sweat. And in-browser OCR (reading text off an image) is good, not perfect. A faint or messy scan can still trip it up. Those are real tradeoffs, and I made them on purpose. They're just not the same species of problem as "your tax return now lives on a server in who-knows-where."

The actual point: this is a skill, not a sales pitch

Forget my tool for a second. Forget PDFs, even.

What I really want you to leave with is this: you are not helpless in front of a website making claims about your data. You don't have to read the privacy policy like a paralegal, and you don't have to take the friendly green "secure" badge at its word. You've got a flight recorder built into the thing you're already using. It reports facts. It doesn't pick the website's side.

Run the test once on a site you use all the time. Watch the Size column. Either you'll see your file leave, or you'll see a boring empty log, and either way you'll know instead of guessing. Try it on a photo compressor. A "convert to Word" site. That one converter your accountant swears by. It takes half a minute and it's oddly satisfying, like finally finding out whether the "close door" button in the elevator does anything at all.

Most people will never open that panel. You're not most people now. Go catch something.

If you want a first site to point the recorder at, the PDF tools here were built to come up empty. Start with those.