In 2024 a security researcher analyzed 20 “free PDF merger” websites and found that 17 of them stored user-uploaded PDFs on temporary CDN storage — and 3 of them had not deleted them after 24 hours. In other words, the contract, medical record, or resume you uploaded today is still on someone else’s disk tomorrow, and you don’t even know it.

PDF is a uniquely sensitive data type. It frequently contains your most private content — ID scans, contracts, pay stubs, medical records, passports, transcripts. But because it “looks like just a document”, people’s mental defense is lower than for, say, naked photos. This article uses 3 real privacy-incident case studies to explain why we insist on all-PDF-processing in the browser, and how you can verify whether any tool actually processes locally.

3 Real Incidents

A “free PDF merger” site, recommended by many, was discovered by a security researcher to have stored 2 million user-uploaded PDFs on AWS S3, with misconfigured bucket permissions allowing public access. The corpus included items that could be tied to real identities: attorney letters, hospital discharge summaries, diplomas.

Root cause: The engineering team used S3 temporary storage for “acceleration cache” (CDN was misconfigured), but the bucket’s IAM permissions were set to public-read. The tool’s upload button didn’t say “upload to S3”; it just said “upload to cloud for processing”.

What the user could have done: Before uploading, press F12 and watch the Network tab. If you see POST requests going to third-party domains, the tool is not pure-frontend.

Incident 2: A “PDF Anonymizer” That Just Visually Blacked Things Out (2024)

A tool marketed as “upload medical records, automatically anonymize all names and addresses” was found by an engineer to use “anonymization” that was just visual masking (drawing black rectangles over the names) — the original text stream inside the PDF still contained the names. Anyone with PDF reverse-engineering skills could extract the original text.

Root cause: True anonymization requires modifying the PDF content stream (rewriting objects with a library like pdf-lib), but visual masking is 1 line of code (draw a rectangle on the page). Low-cost implementation vs high-cost implementation is a business decision.

What the user could have done: Upload a fake “test medical record” filled with TEST NAME test-name, then download the result, open it in a PDF editor and look at the text stream. A truly anonymized PDF should make text-search for any name return nothing.

Incident 3: An OCR Service’s Scan + Training-Data Controversy (2025)

An AI-powered “OCR PDF to Word” tool wrote into its user agreement: “uploaded files may be used to improve our AI models.” Legally this is permitted (the user agreed to the EULA), but no user uploading their contracts realized their contract was training an AI.

Root cause: The “free tool for data” business model. Free tools don’t sell ads (advertisers don’t want to spend money on OCR tools), so they resell data instead.

What the user could have done: Before uploading, scroll to the “data usage” section of the user agreement. It’s usually buried in the middle. From a legal perspective, if data is used for “service improvement”, that usually includes model training.

Why We Insist on Local Processing

Piick PDF Tools has exactly one design principle: files never leave the browser.

Technical implementation:

  • All PDF operations run in the browser process’s memory, using pdf-lib (/src/components/tools/PdfTools.astro)
  • File objects are never wrapped into fetch FormData
  • Button clicks never trigger any network request
  • Processed files directly produce a blob: URL — this URL is internal to the browser sandbox; the outside world cannot see it

Honesty in design:

  • Our privacy page clearly states “no upload, no storage, no training”. This is a promise, not marketing copy.
  • Our code is a static site — there is no backend server to upload to (the piick.cc domain is just HTML + JS + CSS static asset hosting, Astro 4.x build output + CDN cache).
  • We have no account system — no registration, no login, no email.

How to Verify Any Tool You Use Really Does Local Processing

If you’re using another vendor’s PDF tool, do these 3 checks:

Step 1: DevTools Network Monitoring

Open your browser’s developer tools (F12), switch to the Network tab, clear the records. Then use the tool to do one PDF merge.

  • Real local: Network tab should have zero POST/PUT requests (except the page’s first-load HTML/CSS/JS)
  • Fake local: You’ll see upload requests going to a foreign domain (/api/upload.pdf and similar)

Step 2: Firewall Disconnection Test

Disconnect your network (airplane mode or unplug the cable), then do one PDF merge with the tool.

  • Real local: Works completely normally, generates the new PDF
  • Fake local: “Network connection failed” error

Step 3: Read the Code (for Engineers)

Press F12, switch to the Sources tab, search for the PDF processing function (mergePdf or splitPdf). If the function body has no fetch( or XMLHttpRequest call, it’s pure-frontend. If it does, search those fetch URLs and see if they go to your own domain — if they go to *.example.com, it uploaded.

3 Edge Cases to Watch

Edge Case 1: Chromium Extensions

If the tool is a browser extension (Chrome Extension, Firefox Add-on), its “local processing” depends on the extension’s own network permissions. Check the extension settings: Some extensions default to <all_urls> permissions, so even without uploads, they read your pages.

Edge Case 2: The PDF Is Already in the Cloud

If the PDF you’re processing was downloaded from Google Drive or Dropbox (a temporary URL), then after “local processing” completes, the temporary URL access logs still sit on Google/Dropbox’s side. This isn’t the tool’s fault, but be aware.

Edge Case 3: PDF Reader Plugins

Some PDF readers (Adobe Reader DC) have a “Quick Share” feature that pings Adobe’s servers when you open a file. Unrelated to the tool, but the act of opening a PDF may already leak data.

  1. Sensitive PDFs → local tools — contracts, medical records, ID scans, always use a pure-frontend tool (we recommend our own PDF Tools, but any pure-frontend tool will do).
  2. Non-sensitive PDFs → cloud tools are fine — public meeting agendas, public papers, textbooks — cloud tools are no problem.
  3. Empty your cloud tool accounts yearly — if you’ve used ilovepdf or smallpdf accounts, they may have upload history. Log in, check “My files”, delete them yourself.
  4. Important PDFs — never hit a “share to social media” button — these tools almost all process in the cloud.

We built PDF Tools because this matters to us personally, not because we think others do it badly. We genuinely want to give everyone a “trust-free” PDF-processing option.