The Problem: What Actually Happens When You Upload a PDF

When you use any server-based PDF tool — whether it is iLovePDF, SmallPDF, Adobe Acrobat Online, or PDF24 — clicking "Upload" initiates a chain of data handling events that most users never see. Your file is transmitted over HTTPS to a cloud server, where it is temporarily stored on disk (often in a shared filesystem), processed by server-side software, and then returned to you. Between upload and download, your document exists on infrastructure you do not control.

This intermediate step has consequences. During processing, your file may be copied to multiple server nodes, cached in content delivery networks, logged in application logs, or backed up as part of routine infrastructure snapshots. Even if the company's privacy policy says files are "deleted after processing," the reality is more complex. File system deletion marks space as available but does not immediately overwrite data. Backups may retain copies for weeks or months. Application logs may record file metadata (names, sizes, timestamps) indefinitely.

The industry has a pattern of incidents that demonstrate these risks. In 2023, iLovePDF experienced a data breach that exposed user files. In 2024, an employee at a major PDF tool provider was found to have accessed user documents without authorization. These are not isolated events — they are structural risks inherent to any server-based architecture. When your files exist on someone else's server, you are trusting not just the company, but every employee, subcontractor, and infrastructure provider in the chain.

Beyond the direct privacy risks, there are secondary concerns. Server-based tools can correlate your file processing with your IP address, browser fingerprint, and account (if you sign up). This data can be used for analytics, advertising, or sold to third parties. The PDF industry's privacy policies often contain broad language allowing data sharing for "legitimate business interests" — a term broad enough to cover most data monetization strategies.

The Privacy Tax: What You Pay with Free Cloud Tools

Free PDF tools are not free. They monetize you through multiple channels: advertising, data collection, upsells, and account creation funnels. Every time you use a free cloud PDF tool, you are trading your privacy and attention for a service that costs the provider pennies per user in server expenses.

The most common monetization model is advertising. Free PDF tools often display multiple ad placements per page — banner ads, interstitial ads, and sponsored content. These ad networks track you across sessions and websites, building a profile of your behavior. This is fundamentally incompatible with privacy. An ad-supported free tier for a document tool means someone is paying attention to what you are doing with those documents.

Then there is the account creation funnel. Many PDF tools require you to create an account before you can process files. This gives them your email address, which can be used for marketing, sold to third parties, or linked to your file processing history. Accounts also create switching costs — once you have files stored in their cloud, moving to another provider becomes burdensome.

File size limits are another hidden tax. Free tiers on most PDF tools limit you to files under 10MB. If your PDF is larger, you are forced to upgrade to a paid plan — even though the actual processing cost is negligible. These artificial limits exist not because of technical constraints, but to segment users into pricing tiers. NativeSmith's free tier offers 25MB because our costs are essentially zero — there are no servers to pay for.

GDPR and CCPA compliance adds another layer of complexity. Many PDF tool companies claim compliance while relying on "legitimate interest" exemptions to continue collecting and processing user data. The enforcement landscape is improving — 2026 has seen significant GDPR fines for data handling violations — but the burden of enforcement falls on regulators, not on companies voluntarily protecting user privacy. With NativeSmith, there is nothing to enforce. We never have your data in the first place.

Client-Side Processing: How NativeSmith Is Different

NativeSmith is built on a fundamentally different architecture. Instead of sending your files to a server for processing, we bring the processing to your browser. Every PDF operation — merging, splitting, compressing, rendering previews — happens locally on your device using JavaScript libraries that run in your browser's sandboxed environment.

The core of our technology stack is pdf-lib, a pure JavaScript PDF manipulation library that can create, modify, and process PDF files entirely in the browser. For rendering PDF previews, we use pdfjs-dist, the same library that powers Mozilla Firefox's built-in PDF viewer. Both libraries are open source, battle-tested, and auditable by anyone.

For computationally intensive operations — like compressing large PDFs or rendering high-resolution previews — we use Web Workers. These are background threads that run JavaScript in parallel with the main browser thread, preventing the user interface from freezing during processing. The Web Worker has access to the same PDF libraries but no access to the network, DOM, or any other browser APIs that could exfiltrate data.

You can verify that no data leaves your browser by opening your browser's Developer Tools (F12), navigating to the Network tab, and then using any NativeSmith tool. You will see zero network requests during file processing. The only requests are for loading static page assets (the HTML, CSS, and JavaScript files). The actual PDF bytes never travel over the network.

For the Chrome extension, we use Manifest V3 with an offscreen document. The extension requests zero host permissions — it cannot read your browsing data, modify web pages, or communicate with external servers. When you right-click a PDF link and choose "Merge with NativeSmith," the PDF is downloaded locally by the browser, processed by pdf-lib in the offscreen document, and the result is saved to your downloads folder. No network requests at any point.

Competitor Comparison: Who Uploads, Who Doesn't

The table below compares the top PDF tools on the market today. The critical columns are "Upload Required" and "Client-Side Option" — NativeSmith is the only tool that scores "No" on uploads and "Yes" on client-side processing.

Note that Sejda, the closest competitor with privacy-focused messaging, still uploads your files to their servers. Their promise of "deleting files after 2 hours" requires you to trust that the deletion actually happens — and that no copies remain in backups, logs, or analytics pipelines. NativeSmith's "your files never leave your browser" claim is not a promise we have to keep; it is a technical constraint of the architecture. We literally cannot access your files because they never reach us.

Technical Deep-Dive: The Architecture of Privacy

Understanding how NativeSmith achieves client-side processing requires looking at the specific technologies involved and their security guarantees.

pdf-lib: Pure JavaScript PDF Manipulation

pdf-lib is an MIT-licensed, pure JavaScript library that can create, modify, and manipulate PDF files without any native dependencies. It runs in any modern browser, Node.js, Deno, or Bun environment. The library handles all PDF operations — reading page dictionaries, copying objects between documents, compressing streams, and writing valid PDF files — entirely in memory. Because it is pure JavaScript, it operates within the browser's standard security sandbox and has no access to the filesystem or network unless explicitly granted by the user (e.g., through the File System Access API).

pdfjs-dist: Client-Side PDF Rendering

For PDF previews, we use pdfjs-dist, the rendering engine that powers Mozilla Firefox's built-in PDF viewer. This library parses PDF files and renders pages to HTML Canvas elements using the WebGL or 2D canvas API. Like pdf-lib, it runs entirely in the browser and makes no network requests. This means the preview thumbnails you see are generated locally from the PDF bytes in your browser's memory — no pixels are ever sent to a server.

Web Workers: Heavy Processing Off the Main Thread

For computationally intensive operations (compressing large PDFs, processing many pages), NativeSmith uses Web Workers. These are background threads that run JavaScript in parallel with the main browser thread. Critically, Web Workers have no access to the DOM, the network, localStorage, or any other browser API that could be used to exfiltrate data. The worker communicates with the main thread only through message passing, and we pass only the processed PDF bytes back. This isolation provides a strong security guarantee: even if a library vulnerability existed, the attacker would have no way to send data to an external server.

Content Security Policy

NativeSmith enforces a strict Content Security Policy (CSP) that restricts what resources the page can load.

Open Source Transparency

Both pdf-lib and pdfjs-dist are open source with permissive licenses. Their source code is publicly available on GitHub for audit. Any security researcher can verify that these libraries do not make network requests, do not exfiltrate data, and operate within browser sandbox constraints. This transparency is the foundation of trust — we do not ask you to trust our word; we ask you to trust the code that anyone can read.

What "Files Never Leave Your Browser" Actually Means (And What It Does Not)

We want to be precise about what we claim and what we do not. Honesty about the threat model matters — overselling security guarantees helps no one.

Our threat model is focused on server-side risks: the risks that arise when your files exist on someone else's infrastructure. We do not claim to protect against client-side compromise (malware on your device), browser-level surveillance, or network-level observation of domain visits. These are different threat models that require different mitigations (device security, VPNs, Tor, etc.). We protect against the risks we can control, and we are transparent about the limits of that protection.

Pro Pass & Privacy: No Tradeoffs

The Pro Pass is our paid tier, offering unlimited file processing, larger file sizes (up to 500MB), batch operations, and priority support. Crucially, Pro Pass does not change the privacy architecture. Everything remains client-side. The only difference is which features are unlocked.

Pro Pass is implemented as a LocalStorage token — pro_pass_token — that is stored in your browser. This token is verified client-side (there is no backend validation yet, and there may never be one). When Stripe Checkout is integrated, the only data we will receive is your email address for the receipt — never your files, file metadata, or processing history.

We do not require accounts, email signups, or any personal information to use the free tier. Pro Pass requires payment (via Stripe), but the transaction is handled by Stripe's infrastructure — we never see your payment details. Our architecture ensures that even as a paid user, your privacy guarantees remain identical to the free tier.

Frequently Asked Questions

Is it really true that no data leaves my browser?

Yes. NativeSmith uses pdf-lib and pdfjs-dist to process all PDF operations entirely within your browser. We make zero network requests during file processing. You can verify this by opening your browser's Developer Tools (F12), going to the Network tab, and watching — no data is sent to any server. The only network requests are for loading the page itself (static assets like HTML, CSS, and JavaScript). Your PDFs never touch our servers, and we have no way to access your files.

What about the PDF preview — does that go to a server?

No. PDF previews are rendered client-side using pdfjs-dist, a library Mozilla maintains. The PDF file is rendered directly onto an HTML Canvas element in your browser using the WebGL or 2D canvas API. No pixels, no page data, and no metadata are ever transmitted over the network. Everything stays local.

Can you see my files if I use the Chrome extension?

No. The NativeSmith Chrome extension (Manifest V3) processes all PDFs using an offscreen document with pdf-lib. The extension requests zero host permissions — it cannot read your browsing data, cannot modify web pages, and cannot communicate with external servers. The extension stores only your Pro Pass token (if purchased) and a local processing counter in your browser's localStorage. We have designed the extension with the minimum possible permissions.

What happens if I clear my browser data?

Clearing your browser data will remove your Pro Pass token and file processing history from localStorage. Your files are never stored by us, so there is nothing to recover. Your Pro Pass can be restored by logging into your Stripe account and re-authenticating. Your processing history is only maintained locally as a convenience feature.

Do you sell my data?

We cannot sell your data because we never have access to it. NativeSmith processes everything client-side — your PDFs never reach our servers. We do not use analytics trackers, advertising cookies, or third-party scripts that could collect your usage data. We use Plausible Analytics (when enabled) for basic traffic measurement, which is privacy-friendly and does not use cookies. Our business model is straightforward: free tier + Pro Pass subscription. Not data monetization.

Is this compliant with HIPAA/GDPR for my industry?

NativeSmith's architecture makes it inherently compliant with data protection regulations. Because files never leave the browser, there is no data transfer, no data storage by us, and no third-party processing. For HIPAA compliance: no Protected Health Information (PHI) is transmitted to or stored by NativeSmith servers (there are none). For GDPR: no personal data is processed by us — all processing happens on the user's device. However, we recommend consulting your compliance officer, as regulations may have specific requirements beyond our control. We offer a Data Processing Agreement (DPA) for Pro Pass users upon request.

What if I need to process a 500MB PDF?

NativeSmith supports large files using the File System Access API and streaming techniques. The free tier supports files up to 25MB. Pro Pass users can process files up to 500MB or more, limited only by available browser memory. Since all processing happens locally, there are no server-imposed file size limits. For extremely large files, we recommend using a modern browser (Chrome, Edge, or Firefox) with sufficient RAM available.

Can I self-host NativeSmith?

NativeSmith is designed as a hosted service, but the core PDF processing libraries (pdf-lib and pdfjs-dist) are open source. You can integrate them directly into your own applications. The NativeSmith website itself could theoretically be self-hosted since it is a static site exported by Astro. We do not currently offer official self-hosting packages, but the monorepo is available for review.

Related PDF Tools

Ready to Process PDFs Privately?

Free, no account, and your files never leave your browser.