The first thing every cloud-based PDF tool says is "we delete your files after X hours". That's reassuring marketing language, and in most cases it's also true. But "deleted" is only one variable in the privacy equation. Where the file lived during processing, who has the legal right to access it, what the Terms of Service permit beyond what the marketing page implies, and what the company actually logs — these matter just as much. This article audits six popular online PDF services on those questions, then compares them to the alternative model where your files never leave the device at all.
What Actually Happens to Your File
When you upload a PDF to a cloud service, the file goes through five steps:
- Transit. Your browser uploads the bytes via HTTPS to a server somewhere. HTTPS protects against eavesdropping in transit but the server obviously decrypts the file to process it.
- Storage during processing. The server holds the decrypted file in memory or on disk for the duration of the operation. Some services explicitly persist to disk (for resume / multi-step pipelines); others process in-memory only.
- Backup snapshots. Cloud infrastructure (AWS, GCP, Azure) takes automated snapshots of disks. Your file might exist in a backup for hours after the "deleted" timestamp.
- Logs. Most services log the operation: timestamp, file name, file size, IP address, user agent, sometimes the hash of the file content. These logs typically live for 30–90 days.
- Deletion. The actual file is removed. Backup snapshots eventually rotate out (1–7 days, depending on the provider's retention policy).
"We delete your files within 1 hour" usually refers to step 5 — the active file. Steps 3 and 4 (backups and logs) outlive the active file by days.
Audit of Six Popular Services
Based on each service's published Privacy Policy and Terms of Service as of 2026 (always check directly before relying on this — these change):
| Service | Server location | Active file retention | Logs retention | ToS reuse rights |
|---|---|---|---|---|
| SmallPDF | Switzerland | 1 hour | "no specified period" | "necessary to provide the service" |
| iLovePDF | Spain (EU) | 2 hours | 24 months | "improve the service" |
| PDF24 (web) | Germany | 30 minutes | 90 days | None claimed |
| Adobe Online | US (multiple regions) | 24 hours | 13 months | "machine learning improvement" with opt-out |
| Sejda Online | Romania (EU) | 5 hours | 90 days | "service operation" only |
| PDFcandy | Various | 2 hours | "limited" | Standard |
The services with the strictest published policies are PDF24 and Sejda — both EU-based, both explicitly limit log retention, both have the cleanest ToS regarding what they can do with your file content.
The services to watch are Adobe Online (24-hour retention is long, and the ML improvement clause is broad) and SmallPDF ("no specified period" for logs is a yellow flag).
None of these are doing anything illegal or even unusual — these are standard SaaS retention policies. The point is not that they're bad actors; the point is that even with a generous reading, your file is observable by their infrastructure for hours and your file's metadata for months.
What "Privacy-First" Actually Means
Two genuinely privacy-first models exist:
Browser-based (WebAssembly) processing
Tools like ToolK.io, the local PDF24 Creator (desktop), Stirling-PDF (self-hosted), and Inscribe (open-source) run the transformation in your browser via WebAssembly. The file is read into a JavaScript ArrayBuffer in tab memory, transformed locally, and the result is downloaded directly from your browser as a Blob.
What that means concretely:
- The file never leaves your device. There is no upload step.
- The site has no infrastructure to log because no infrastructure is involved.
- The closest thing to a "log" is the page-load entry in the site's Vercel/Cloudflare access logs (timestamp, IP, user agent, URL). The file content and operation are invisible.
- No backup snapshot can include your file because no server held it.
- The Privacy Policy can honestly state "we never see your files" because the architecture makes it impossible.
The trade-off is that some heavy operations (deep OCR on bad scans, huge files over 100 MB, complex PDF→Word conversion with table reconstruction) are slower or weaker than what server-side compute can deliver.
Self-hosted server
Stirling-PDF and a handful of similar projects let you run the same kinds of cloud services on your own infrastructure (a home server, a VPS, a Docker container). Your files go to your server, processed on your hardware, with retention policies you set.
This is the most flexible privacy model but requires technical comfort with Docker / a home server. Not for non-technical users.
What Browser-Based Tools Actually Cover
The honest answer is "most everyday PDF operations":
- Merge, split, rotate, watermark, page numbers, page deletion ✓
- Compress (good results, sometimes 10-20% larger than the best server-side tools at equivalent quality)
- Sign / fill / annotate ✓
- Encrypt / decrypt with password ✓
- OCR (acceptable on clean scans via tesseract.js; weaker than commercial engines on degraded scans)
- PDF → Word (acceptable on simple layouts; weaker than commercial on complex tables)
- Image → PDF, PDF → Image ✓
- Metadata cleanup ✓
The 10% of cases where cloud services genuinely win are: archival OCR of bad scans, complex form filling with PDF/A compliance, heavy batch operations (1000+ files), and team collaboration features with shared storage.
Choosing Based on the Document
A practical heuristic by document type:
| Document | Recommended tool type | Why |
|---|---|---|
| Generic PDF (downloaded brochure, manual) | Either | Privacy not material |
| Personal contract / NDA | Browser-based | Avoid sending to a third party |
| Financial statement / tax doc | Browser-based | Privacy + ToS scope concerns |
| ID copy / passport scan | Browser-based or self-hosted | Identity data, never to third-party |
| Medical record | Browser-based or self-hosted | HIPAA / equivalent privacy law |
| Business confidential (M&A, legal) | Self-hosted | Even browser-based involves trust in JS bundle integrity |
| Heavy scanned archive (badly scanned 1990s reports) | Cloud (iLovePDF / Adobe) | Their commercial OCR genuinely beats local options |
| Routine batch processing (100+ generic PDFs) | Cloud or self-hosted | Browser memory limits |
A Concrete Test
If you want to verify a tool's privacy claims yourself:
- Open browser DevTools → Network tab.
- Drop a small PDF into the tool.
- Click the operation (merge, compress, whatever).
- Watch what gets uploaded.
For a true browser-based tool, you'll see the page assets load (HTML, JS, WASM) but no upload of your PDF bytes. For a cloud service, you'll see an HTTP POST with your file size's worth of bytes leaving for a server.
This 30-second test is the most reliable privacy audit any user can do.
The Bottom Line
For everyday PDF work, all the cloud services in the audit table above do their job competently and aren't doing anything sinister. If your PDFs aren't sensitive, the privacy difference is academic. But for anything that contains personal, financial, legal, or medical information — and for anyone who simply prefers their files to stay on their device — the browser-based and self-hosted alternatives have matured enough in 2026 to genuinely cover most workflows. The cost is zero, and the only thing you give up is the cloud's edge on the hardest 10% of operations.
Read the Privacy Policy of any tool you're about to upload sensitive files to. The marketing page rarely tells the whole story.