Why Your Files Should Never Leave Your Browser

Most online file tools — including popular services like iLovePDF, Smallpdf, and PDF2Go — upload your documents to remote servers for processing. Your contracts, tax forms, medical records, and personal photos pass through third-party infrastructure, are stored temporarily, and are subject to security practices you can't verify. PDFJolt takes a fundamentally different approach: every file operation happens entirely in your browser using WebAssembly, and your documents never leave your device.

The Problem: Server-Side File Processing

When you use a typical online PDF tool, here's what actually happens:

1. You select a file on your computer
2. The website uploads your file to their server (a POST request, usually to AWS, Google Cloud, or a similar provider)
3. Their server processes the file (merging, compressing, converting, etc.)
4. The processed file is sent back to your browser for download
5. The original and processed files sit on their server until a cleanup job deletes them (typically 1-2 hours later)

This means your file exists on someone else's computer — potentially in a different country, subject to different privacy laws — for at least some period of time. For a vacation photo or a public flyer, this might be acceptable. For a signed contract, a W-2 tax form, a medical record, or a confidential business document, it's a risk you probably shouldn't take.

What Can Go Wrong

The risks aren't theoretical. According to the 2025 Verizon Data Breach Investigations Report, web application attacks were the #1 pattern in data breaches, accounting for 26% of all incidents. Cloud storage misconfigurations — like an S3 bucket set to public instead of private — remain one of the most common breach vectors.

Even if the file processing service has good security, several things can go wrong:

• Data breaches. No server is invulnerable. If the service is breached, files in temporary storage could be exposed.
• Employee access. Server-side processing means employees or contractors could potentially access uploaded files — intentionally or accidentally.
• Metadata leakage. Even if the file itself is deleted, logs may retain metadata: file names, sizes, IP addresses, timestamps. A file named "2026-tax-return-john-smith.pdf" reveals sensitive information even without the file content.
• Retention failures. "Files deleted after 1 hour" is a policy, not a guarantee. Backup systems, caching layers, CDN nodes, and logging pipelines may retain copies longer than advertised.
• Jurisdiction issues. If the server is in a different country, your file may be subject to that country's data access laws. Government requests for data follow the server's location, not yours.

The Solution: Client-Side Processing

Client-side processing flips the model entirely. Instead of sending your file to a server for processing, the processing code runs in your browser. Your file never leaves your device.

How It Works

When you use PDFJolt to compress a PDF, merge documents, or sign a PDF, the following happens:

1. You select a file on your computer
2. The file is read into your browser's memory (JavaScript FileReader API)
3. Processing libraries compiled to WebAssembly operate on the file in memory
4. The result is offered for download via a Blob URL (a temporary local reference)
5. When you close the tab, the memory is released and the data is gone

At no point does the file travel over the network. The processing happens on your CPU, in your browser's sandboxed environment. No server is involved.

WebAssembly: The Technology That Makes It Possible

Five years ago, client-side file processing was impractical. JavaScript was too slow to handle operations like PDF rendering, image compression, or OCR in any reasonable time. You had to send files to servers because that's where the computational power was.

WebAssembly (WASM) changed this. WASM is a binary instruction format supported by all modern browsers that runs at near-native speed — typically within 10-20% of compiled C/C++ performance. Libraries originally written in C, C++, or Rust can be compiled to WebAssembly and executed in the browser.

PDFJolt uses several WebAssembly-powered libraries:

• pdf-lib — PDF creation, manipulation, and form filling
• pdf.js — PDF rendering (the same library used by Firefox's built-in PDF viewer)
• Canvas API — Image processing, resizing, and format conversion

These libraries run entirely in your browser. They don't need a server any more than a calculator app needs the internet.

How to Verify a Tool Processes Files Locally

Don't take any tool's privacy claims at face value — including ours. Here's how to verify for yourself that a tool isn't uploading your files:

The Network Tab Test

1. Open your browser's Developer Tools (press F12 or right-click → "Inspect")
2. Go to the Network tab
3. Clear any existing entries
4. Use the file tool as normal — upload a file, process it, download the result
5. Look at the Network tab entries. Sort by size (largest first).

What server-side tools look like: You'll see a large POST request (matching your file's size) sending data to an API endpoint. Then a large response (the processed file) coming back. The file traveled round-trip to a server.

What PDFJolt looks like: You'll see small requests for page assets (JS, CSS, fonts) but zero large uploads. The file stays in your browser's memory. The largest request might be a few kilobytes for analytics — never your file.

We encourage every user to perform this test. Transparency is the foundation of trust.

Privacy Audit: Popular Online PDF Tools

We analyzed the network behavior of five popular online PDF tools in January 2026. Here's what we found:

Tool	Uploads File to Server	Server Location	Retention Policy	Encryption in Transit
PDFJolt	No (client-side)	N/A	N/A (nothing stored)	N/A
iLovePDF	Yes	EU (Barcelona)	2 hours	TLS 1.3
Smallpdf	Yes	EU (Zurich)	1 hour	TLS 1.3
PDF2Go	Yes	EU (Germany)	24 hours	TLS 1.2
Adobe Acrobat Online	Yes	US (AWS)	"Limited time"	TLS 1.3

Every competitor in this comparison uploads your file to their servers. The retention periods range from 1 hour to 24 hours, and Adobe's policy uses vague language ("limited time") without specifying an exact duration.

To be clear: these services use encryption in transit (TLS), which protects the file while it's being uploaded. But encryption in transit doesn't protect the file while it sits on their server, and it doesn't prevent server-side access by employees, contractors, or attackers who breach the server.

What About "Encrypted" Cloud Processing?

Some tools advertise "encrypted processing" or "secure cloud processing." This typically means:

• The file is encrypted during upload (TLS) — this is standard for any HTTPS website
• The file may be encrypted at rest on their servers — but they hold the encryption key
• The file is decrypted for processing — because the server needs to read it to manipulate it

This is better than nothing, but it's fundamentally different from client-side processing. With server-side processing, the service can access your file. They choose not to (according to their policy), but the capability exists. With client-side processing, the service cannot access your file. There's no trust required — the architecture makes it impossible.

When Server-Side Processing Is Acceptable

Client-side processing isn't always possible or necessary. Here are cases where server-side tools are reasonable:

• Non-sensitive files. Public marketing materials, open-source documentation, and personal photos don't carry privacy risk.
• OCR on large documents. Optical Character Recognition is extremely CPU-intensive. Processing a 200-page scanned document client-side could take 30+ minutes, while a powerful server can do it in 2-3 minutes. For non-sensitive scans, the tradeoff may be worth it.
• Advanced AI features. Some operations — like intelligent document classification, handwriting recognition, or AI-powered table extraction — require machine learning models too large to run in a browser. These genuinely need server-side compute.
• Batch processing at scale. Processing 500 files simultaneously is better suited to server infrastructure than a browser tab.

The key is making an informed choice. If you're processing a public flyer, use whatever tool is most convenient. If you're processing a tax return with your Social Security Number, use a tool that never receives your file.

The Regulatory Landscape

Privacy regulations are increasingly relevant to document processing:

• GDPR (EU) — Requires explicit consent before processing personal data, and grants individuals the right to have their data deleted. If an online tool stores your document (even temporarily), it's processing your personal data under GDPR.
• CCPA/CPRA (California) — Similar rights for California residents, including the right to know what data is collected and the right to delete.
• HIPAA (US Healthcare) — Protected Health Information (PHI) cannot be stored on systems that aren't HIPAA-compliant. Most free online PDF tools are not HIPAA-compliant, making them unsuitable for medical documents.
• SOC 2 (Enterprise) — Many enterprises require SOC 2 compliance for any service that handles their data. Free online tools rarely have SOC 2 certification.

Client-side processing sidesteps all of these concerns because no personal data leaves the user's device. There's nothing to store, nothing to delete, nothing to regulate — because the service never receives the data in the first place.

How PDFJolt Handles the Edge Cases

PDFJolt processes everything client-side for the free tier. Here's how we handle scenarios that typically require a server:

• Large files: Modern browsers can handle files up to several hundred megabytes. For most document processing (merging, compressing, signing), this is more than sufficient.
• CPU-intensive operations: WebAssembly runs at near-native speed. Operations that would have been impractical in JavaScript five years ago now complete in seconds.
• Complex conversions: PDF to Word, PDF to Excel, and image format conversions all run client-side using specialized WASM libraries.

For Pro and API users who need server-side processing for batch operations or very large files, PDFJolt uses temporary processing with immediate deletion and never retains file content beyond the processing window. But the free tier — which is what most people use — is 100% client-side.

A Simple Rule

Next time you need to process a file online, ask yourself: "Would I be comfortable if this file was posted publicly?"

If the answer is yes — a restaurant menu, a concert flyer, a public event schedule — use whatever tool is convenient.

If the answer is no — a contract, a tax form, a medical record, a bank statement, a password list, employee records, legal correspondence — use a tool that processes files locally. Open the Network tab and verify.

Your files contain your life. They shouldn't leave your device unless absolutely necessary.

Try PDFJolt's PDF tools, merge tool, and signature tool — all free, all client-side, all private.