What Happens to Your PDF After You Hit 'Choose File'

It's Thursday afternoon and the letting agent wants your rental application as a single file: employment contract, two pay slips, credit report, a scan of your ID. You type "merge PDF" into the search bar, click the first result, drag four files into the box, wait five seconds, download the result and close the tab.

Hardly anyone has ever read up on what happened during those five seconds. Yet most of it is publicly documented — you just have to know where to look. And it's rarely the page with the padlock icon and the word "secure" on it.

This article deliberately names no providers. Instead, it shows you how to size up any service yourself in a few minutes — including us.

The Journey Your File Takes

When a server-based online tool processes your PDF, it doesn't do so in your browser. It does it in a data center, and your file has to get there first. The route typically looks like this:

Your browser packages the file and sends it over HTTPS to a load balancer, which hands it to a processing node. There it lands — depending on the architecture — in RAM, on a temporary disk, or straight in an object store like Amazon S3. A worker process performs the actual operation. The result is stored again, usually behind a randomly generated URL so you can download it. Meanwhile, the web server, the load balancer and the application are all writing their log files. Object stores replicate across multiple locations. Backups run on their own schedule.

None of this is a criticism — it's solid engineering, and it's how you build services that scale. But it explains why "deleted" is a word with more meanings than you'd assume. The delete command reliably hits the file you uploaded. Whether it also reaches every replica, every backup and every log line is a question of implementation — and no privacy policy answers it.

How to Read a Deletion Policy

Here comes the most useful part of this article, and it costs you five minutes per provider.

Landing pages, help articles and FAQs quote numbers like "deleted after one hour." That's marketing copy. What's legally binding is the privacy policy. Put the two side by side and watch for five things:

1. Do the numbers match? Find the retention section in the privacy policy and compare it with what the product page says. Experience suggests the comparison is worth your time.

2. Does the clock start at upload, or at last access? That's a massive difference. A period counted "from last opening" isn't a clock — it's a timer that restarts every time the file is touched.

3. Does the same period apply with and without an account? Many people deliberately skip creating an account in order to leave fewer traces. Check whether that actually means shorter retention in your case, or longer — the answer isn't always the one you'd expect.

4. Are there exceptions for individual tools? Electronic signatures, for instance, require longer retention for evidentiary reasons; that's perfectly legitimate, but it often appears only in the fine print for that particular tool.

5. What date is on the document? If the privacy policy is noticeably older than the newest features in the menu — AI tools for summarizing or translating, say — it's worth asking which subprocessors were added to make those work.

Point five is the most current one. AI features almost always require additional service providers behind the scenes. If you want to know where your document actually ends up, the answer lives in the list of subprocessors — never on the product page.

The Irony of the Most Sensitive Tools

Take a look at a typical tool list. Two functions show up almost everywhere, and with both of them the upload approach develops a peculiar logic of its own:

"Redact PDF." You black out passages because the document, in its original form, must not fall into the wrong hands. To achieve that, you transmit it to a third party — in its original form.

"Remove PDF password." You have an encrypted file — the bank statement, the insurance certificate, the pay slip. To strip the protection, you transmit the file and the password.

That's not an accusation against anyone; server-side, there is technically no other way to do it. But these are precisely the two cases where three seconds of thought pay off.

Metadata Is Data Too

Privacy policies frequently distinguish between the file itself and its metadata — file name, file size, file type. Metadata often falls under more generous rules, such as analysis for product improvement.

That sounds harmless until you think about the file names that actually sit on people's hard drives. Termination_Smith_final.pdf. Oncology_diagnosis_2024.pdf. Divorce_settlement_draft3.pdf. The contents stay sealed; the headline doesn't.

That this is no theoretical problem becomes clear with one look at Have I Been Pwned. The entry for a major PDF service compromised in 2020 explicitly lists — alongside names and password hashes — the titles of converted documents among the exposed data categories.

Three Documented Incidents

The following cases are publicly documented and verifiable through the sources named. They concern only the services described there and allow no conclusions about other providers.

September 2020 — the scope was initially played down. A publicly listed PDF provider reported a security incident with minor impact to its stock market regulator; customer data, it said, was not affected. A few months later, a well-known threat group published the complete database: 14 GB, a good 77 million records. Before that, a package consisting of this database plus roughly a terabyte of documents had been put up for sale at a starting bid of $80,000. (Documented by BleepingComputer and Have I Been Pwned.)

July 2024 — the storage was simply left open. The research team at Cybernews found two PDF services whose Amazon S3 storage was reachable on the open internet without any access restrictions at all. At the time of publication, a good 89,000 files were freely accessible, including passports, driver's licenses, contracts and academic records. According to the report, several attempts to contact the operators went unanswered — while documents kept being uploaded. (Documented by Cybernews.)

March 2025 — the fake converters. The FBI's Denver field office issued a public warning about fraudulent conversion sites. They actually perform the promised task — except the document they hand back carries malicious code. According to the FBI, some of these operations additionally scrape the uploaded files for personal information, banking details and cryptocurrency data. A spokeswoman for the office told reporters that the people most at risk are those who type "free online file converter" into a search engine, because the top results are frequently paid ads. (Press release, FBI Denver Field Office, March 2025.)

The third case matters most for everyday life, because it has nothing to do with carelessness at reputable companies. It describes services built as traps from the outset — which, to the user, look exactly like all the others.

How Germany Regulates This: Two Duties, Not One

It's worth examining one jurisdiction in detail, because Germany is unusually explicit about what handing a document to a third-party service legally means. One caveat before we start: the GDPR rules below apply across the entire EU, while the criminal-law provision, § 203, is specifically German — if you're reading this from elsewhere, treat it as a case study, not as your own law. For private individuals this is a matter of judgment; for companies and certain professions it's a matter of law. What follows describes the legal situation and is no substitute for legal advice in an individual case.

Processing on behalf of a controller. A company that passes a document containing personal data to an external service is outsourcing a processing operation. The Chamber of Commerce and Industry for Munich and Upper Bavaria puts it bluntly in its guidance on website privacy: even activities like file conversion count as processing on behalf of a controller within the meaning of the GDPR — which means a contract under Art. 28 GDPR is required. And further: the obligation only falls away if no personal data is processed at all. Without that contract there is a violation, even if the service provider performs flawlessly; the fines in this category run up to 10 million euros or two percent of global annual revenue (Art. 83(4) GDPR).

Many established providers do offer such a contract. It's just that virtually nobody who wants to quickly merge two pages ever signs one.

Professional secrecy. For German lawyers, doctors, tax advisors, notaries and psychotherapists, § 203 of the Criminal Code (StGB) comes on top. Until 2017 the situation was delicate: any handover to an external IT provider could constitute an unlawful disclosure. A reform law — in force since November 9, 2017 — created the category of the "other participating person." Under § 203(3) sentence 2 StGB, disclosure to such a person is permitted insofar as it is necessary for using the service, with flanking provisions in the professional codes (§ 43e BRAO for lawyers, § 62a StBerG for tax advisors, § 26a BNotO for notaries, § 50a WPO for auditors).

The catch sits in subsection 4: the professional must contractually bind the service provider to secrecy and inform them that breaching it is a criminal offense. Whoever skips this step becomes criminally liable themselves. A GDPR data processing agreement does not take care of it — that contract governs data protection, not criminal law. They are two separate duties, and the second one is routinely overlooked.

So a lawyer who casually runs a client brief through a free online converter has, in all likelihood, fulfilled neither.

The Alternative: Compute Where the File Already Is

The reason PDF processing historically happened on servers is technical. A PDF isn't a text format; it's a binary structure with cross-reference tables, embedded fonts and object trees. Taking one apart cleanly and writing it back requires a serious library — and for decades those libraries were written in C or C++ and didn't run in a browser.

WebAssembly dissolved that constraint. The same libraries can be compiled into a binary format that the browser executes at near-native speed. The workflow then looks like this:

1. You pick a file. The browser hands it to the JavaScript code through the File API as an ArrayBuffer — no network traffic involved.
2. A WebAssembly module — usually running in a Web Worker so the interface stays responsive — processes the bytes in the tab's memory.
3. The result is created as a Blob and offered for download via an object URL.
4. You close the tab. The memory is released.

At no point does the file leave your device. The toolbox for this is real and mature: PDF.js from Mozilla has been rendering PDFs in Firefox for years. pdf-lib creates and modifies documents in pure JavaScript. MuPDF.js from Artifex brings the full MuPDF engine into the browser as WebAssembly. Tesseract.js makes text recognition possible locally. And for the hardest case — Word or Excel to PDF — there has been ZetaOffice from allotropia since November 2024: a LibreOffice build compiled to WebAssembly, complete with JavaScript bindings.

What Honestly Remains Hard Client-Side

An article that lists only advantages is an advertisement. So here's the other side of the ledger:

Memory. The prevailing wasm32 can address at most 4 GB — not a soft limit, but the entire address space of a 32-bit pointer. Since WebAssembly 3.0 (September 2025) there is 64-bit addressing, but browsers cap it at 16 GB, it costs performance, and support is not equally far along everywhere. In practice that means a 400-megabyte scan with 800 pages can kill the tab on an older smartphone. A server doesn't have that problem.

Load time. A WebAssembly module carrying a full PDF stack weighs several megabytes. On first visit it has to be downloaded — after that it sits in the cache and the page even works offline, but the first impression is slower than with a server tool.

And the most important point, which applies to us as well: client-side does not automatically mean privacy-friendly. The site still sees your IP address. Analytics scripts, error logging and ad networks operate entirely independently of where the PDF gets processed. A service that computes locally while embedding five trackers has only solved half the problem. So don't just ask whether the file stays where it is — ask what else is flowing out. Of every provider, including this one.

The Test You Can Run Yourself in 30 Seconds

You don't have to take anyone's word for anything. Two checks that work on any website:

The network test. Open the developer tools (F12 or Ctrl+Shift+I; Cmd+Option+I on a Mac), switch to the "Network" tab and filter for "Fetch/XHR." Then process a file. A server-based tool will produce a POST request right there, with a transferred payload roughly the size of your file. With local processing, nothing shows up.

The offline test. Even simpler, and impossible to spin: load the page, then turn off Wi-Fi or switch on airplane mode — and keep working. Whatever functions without an internet connection has, guaranteed, transmitted nothing.

Feel free to run both tests on this very page. We would want it no other way.

A Rule of Thumb to Take With You

Before you click "Choose file," ask yourself a single question: Would I email this document to a stranger who promises to delete it after two hours?

For the menu for the club's summer party: sure. For the board presentation, the medical records, the client brief, the ID scan: probably not.

And when the answer is "probably not," the good news is that you don't have to choose between convenience and caution. These days, the browser can do the job itself.

Last updated: July 2026. This article describes general technical mechanisms and the legal situation; it does not assess individual providers and does not constitute legal advice. To evaluate a specific service, please check its current privacy policy yourself.