Every time you use an online PDF tool, you're making a quiet decision: "I trust this company with my document."
Most people don't realize they're making it.
I didn't either — until I started building RaptorPDF, a PDF editor that processes files entirely in your browser. Along the way, I spent weeks analyzing how the most popular online PDF tools actually handle your files. What I found changed how I think about "free" software.
The upload problem nobody talks about
Here's how virtually every popular online PDF tool works:
- You select your file
- It uploads to their server
- Their server processes it
- The processed file is sent back to you
- The original file sits on their server — for how long? Unclear.
Tools like iLovePDF, Smallpdf, PDF2Go, and dozens of others follow this model. It works fine for most documents. But think about what people actually put in PDFs:
- Tax returns and financial statements
- Medical records and prescriptions
- Legal contracts with personal details
- ID scans and passport copies
- Confidential business documents
- HR records and salary information
These files are uploaded to servers you know nothing about — their security practices, data retention policies, breach history, or which jurisdiction governs them.
What their privacy policies actually say
I read through several of their privacy policies so you don't have to.
Most say something along the lines of: "We delete your files after X hours/days." Some say 1 hour, some say 24 hours, some say a week. iLovePDF says they delete files after "a short period." Smallpdf says files are deleted "within a few hours."
The problem: these are promises, not guarantees. You have no way to verify this. You're trusting that:
- Their deletion systems work correctly
- They haven't had a breach before the deletion
- Their employees don't access files
- Third-party processors they use follow the same rules
- Their backup systems don't retain copies
For a contract renewal or a homework PDF? Fine, probably. For your medical records or tax return? That's a meaningful risk you're unknowingly taking.
The WebAssembly solution
When I decided to build a privacy-first PDF tool, the key question was: can all of this happen in the browser?
The answer, thanks to WebAssembly, is yes.
Modern browsers can run near-native code through WebAssembly (WASM). Libraries like pdf-lib, PDF.js, and compiled C++ PDF processing libraries can run directly in the browser, accessing your local files through the File API — without ever sending bytes to a server.
Here's the flow in RaptorPDF:
User selects file
↓
File loaded into browser memory (File API)
↓
WebAssembly/JS processes the PDF locally
↓
Result available for download
↓
File never leaves the device
No upload. No server processing. No retention question.
What this enables (and what it can't do)
Works great client-side:
- Merging and splitting PDFs
- Compressing PDFs (using re-rendering)
- Adding text, annotations, highlights, drawings
- Password protection and removal
- Page reordering, deletion, resizing
- Image to PDF conversion
- Digital signatures
Still requires a server (for now):
- True OCR (recognizing text in scanned documents)
- High-fidelity PDF to Word conversion
- Complex AI-powered features
The honest truth: for about 80% of what people use PDF tools for, client-side processing works perfectly. The remaining 20% — mostly OCR and complex format conversion — still benefits from server processing. We're transparent about which features do and don't upload files.
The unexpected engineering challenges
Building a browser-based PDF editor sounds straightforward. It wasn't.
Memory limits: Browsers have memory constraints. Large PDFs (100+ pages, embedded images) can exhaust available memory. We had to implement chunk-based processing and warn users about file size limits before they hit the wall.
iOS/Safari quirks: WebKit handles WebAssembly differently. Features that worked perfectly in Chrome needed extra work for Safari, especially for file downloads and large file handling. (If you've built anything for iOS WebView, you know the pain.)
Compression trade-offs: Client-side PDF compression works by re-rendering — which means some quality loss is inevitable. We added quality sliders so users can control the trade-off.
Cross-browser file download: Triggering a file download after processing sounds trivial. It's not. Different browsers handle blob URLs, service workers, and large file downloads differently.
Why "no upload" is becoming more important, not less
GDPR, HIPAA, and similar regulations are increasingly holding organizations accountable for where their data goes — including when employees use third-party tools for work documents.
A lawyer uploading a client contract to an online PDF tool is potentially violating their client's confidentiality. A healthcare worker compressing a patient PDF is potentially a HIPAA issue. A finance employee merging salary spreadsheet PDFs is potentially leaking PII.
Browser-based processing sidesteps these concerns entirely. If the data never leaves the device, there's no data transfer to regulate.
Building RaptorPDF
RaptorPDF started as a weekend project and grew into something more complete. It now offers 20+ tools — merge, split, compress, convert, annotate, sign, protect — all running client-side.
It's free to use (with a Pro tier for power users who need larger files and unlimited operations). No signup required for most features.
The stack is deliberately minimal: vanilla JS, WebAssembly for heavy lifting, and a static site that can be served from a CDN. No complex backend, no database of user files, nothing to breach.
The broader lesson
The "free" in free online tools often has a hidden cost: your data. Sometimes that's fine — you're giving Google your search queries for a useful service, and that trade-off is well-understood.
But with sensitive documents, the calculus is different. The information in a PDF can be genuinely personal and genuinely valuable. It deserves a tool that's designed around protecting it — not one that incidentally mentions it in a privacy policy.
If you work with sensitive PDFs and haven't thought about where they actually go when you use online tools, it's worth taking a minute to think about it.
And if you want to try a tool that's built around not seeing your files at all: https://www.raptorpdf.com
I'm happy to go deeper on any of the technical details — the WebAssembly integration, iOS WebView quirks, or the compression approach. Drop a comment if you want a follow-up post on any of these.