Rohman
Think about the last PDF you edited online. Maybe it was a contract, a tax return, or a medical form. You uploaded it to some website, waited for it to process, and downloaded the result.
Quick answer: local-first PDF processing skips the upload. When you merge, split, compress, or edit a file in OxygenPDF, it never leaves your device — your browser reads the bytes, does the work itself, and writes the result back to your disk.
That's the whole pitch. It's also worth understanding why it holds up, and where it doesn't.
Key takeaways
- OxygenPDF's tools run entirely inside your browser tab — JavaScript for structural edits, WebAssembly for heavier lifting like OCR.
- A cloud tool's "delete" usually means a database flag, not erased bytes. Backups and logs commonly outlive the file itself.
- Local-first is also faster for most operations, because there's no upload/download round trip to wait on.
- OCR is the one place local processing can lose to a server GPU. OxygenPDF gives you a local engine and an optional cloud engine, chosen per file.
- There's no hard upload ceiling on the free web app. Your device's memory is the real limit, not a server-side quota.
What "Local-First" Actually Means
"Local-first" describes where the computation happens, not just where the file sits afterward. A cloud PDF tool uploads your file to a server, runs its merge, split, compress, or OCR logic there, and sends a result back down. A local-first tool runs that same logic on your machine, inside the browser tab you already have open, using the browser's own JavaScript engine and, for anything heavier, WebAssembly modules that run compiled C, C++, or Rust code at near-native speed (MDN's WebAssembly reference covers what that actually means under the hood).
The distinction matters because "your file is safe with us" is a promise about behavior, and behavior can change with a policy update, an acquisition, or a misconfigured server. "Your file never left your device" isn't a promise. It's just what happened, and you can check it yourself, which we'll get to.
What Cloud PDF Tools Actually Do
Upload, process, download. Simple enough on the surface. The infrastructure behind that "process" step is messier than most people realize.
Your file passes through load balancers, gets copied to temporary storage during processing, and can end up referenced in logs that capture more than the service intended, whether that's a request URL with a filename in it or a debug trace that includes a fragment of file content. This isn't a hypothetical edge case; it's common enough that the OWASP Logging Cheat Sheet devotes a section to keeping sensitive data out of application logs in the first place, precisely because it keeps ending up there by accident.
When the service says it "deleted" your file afterward, that typically means a database record got flagged, not that the underlying bytes were wiped from disk. This isn't a cloud PDF tool being shady; it's how storage works almost everywhere. NIST's guidelines on media sanitization exist as a whole standard (NIST SP 800-88 Rev. 1) precisely because "delete" and "actually erase" are different operations, and getting from one to the other requires a deliberate extra step that a routine file-processing pipeline has no reason to take. Backups compound this: a nightly snapshot taken before you deleted the file can keep a copy alive for as long as the vendor's retention window says, and that window is rarely something you can check without emailing support and waiting for an answer.
None of this requires bad intent anywhere in the chain. It's just what happens when more systems touch a file: more systems each have to individually get "forget this" right, and the odds that all of them do drop with every system you add.
Local-First: Your Files Stay Put
When you use OxygenPDF, your browser does all of the work that a server would otherwise do. The file is read from your disk into memory as a File object, processed with pdf-lib and PDF.js for structural operations, and handed to WebAssembly modules for anything more demanding, like OCR. The file's bytes never touch fetch, XMLHttpRequest, or any other network API — there's no wire for them to travel on, because the entire operation is a function call inside your own tab.
That containment isn't just a design choice we're describing after the fact; it's enforced by the browser underneath us. Modern browsers isolate each site into its own sandboxed process specifically so that one page can't read another page's memory or reach across origins (Chromium's Site Isolation is the most documented version of this, and Firefox and Safari ship equivalent protections). A PDF tool that runs purely client-side inherits that isolation for free. There's no server-side data store for a breach to hit, no third-party subprocessor to vet, and no "who else has access" question to ask, because the data was never copied anywhere outside the sandbox your own browser already put it in.
We wrote in more detail about the actual engineering behind this — why pdf-lib handles structural edits, why PDF.js does rendering and decryption, and why OCR specifically needs WebAssembly — in Building PDF Tools with WebAssembly.
Cloud vs. Local-First, Side by Side
| Typical cloud PDF tool | OxygenPDF (local-first) | |
|---|---|---|
| Where processing happens | A remote server | Your browser tab |
| What crosses the network | The whole file, twice — once up, once back down | Nothing but the web app's own code |
| What "delete" means | A database flag; backups and logs may persist regardless | There was never a copy anywhere else to delete |
| Works without a connection | No | Yes, once the tab has loaded |
| File size ceiling | Set by the service's server capacity and pricing tier | Set by your device's available memory |
It's Also Just Faster
Processing starts the instant you drop a file, because there's no upload to wait on first. On a typical laptop, merging ten PDFs takes around 200 milliseconds. Splitting a 100-page PDF takes about half a second. Compressing a file takes a couple of seconds, more if it has a lot of embedded images to re-encode. We measured these ourselves while building the tools, and wrote up the full numbers in the WebAssembly engineering post linked above.
The CPU work itself can be genuinely slower than a beefy server would manage it — your laptop isn't racked in a data center. But wall-clock time usually wins anyway, because there's no round trip to a data center and back eating into the total. Upload speed is often the actual bottleneck in a cloud tool, and it's one local-first processing simply doesn't have.
After the first page load, the current tab keeps working without a network connection at all, since nothing about the operation needs one. And there's no hard upload cap: a friendly nudge toward the paid plan appears if you're on the free tier and drop a file over 50MB, but it doesn't block you from processing that file. Your device's available memory is the real ceiling, not an arbitrary number a server operator picked to control their own hosting costs.
Where It Gets Tricky
Your laptop isn't a data center, so CPU-heavy tasks take longer than they would on dedicated server hardware. Merging, splitting, and compressing are fast enough that the difference is invisible in practice. OCR is the one place it isn't: recognizing text in a scanned page through a WebAssembly build of Tesseract, or through PaddleOCR running on ONNX Runtime Web, takes a few seconds per page rather than a fraction of one, especially on an older laptop or a phone.
That's a real trade-off, so we give you both sides of it instead of picking one for you. OxygenPDF's client-side OCR engines never send a page image anywhere. If you'd rather trade privacy for speed and accuracy on a specific file — a batch of a couple hundred receipts where OCR quality matters more than where the processing happens — there are optional cloud OCR engines that send page images to a server for recognition. You choose per file, engine by engine; nothing gets silently routed off-device because a queue got long.
Browser memory is a real ceiling too, not just a theoretical one. A browser tab's practical memory ceiling is a few GB in practice, varying by browser and platform, and a large PDF packed with high-resolution images can bump against that number faster than the page count alone would suggest. Processing pages one at a time and releasing memory as we go pushes that ceiling further out than it would otherwise be, but a genuinely massive file can still hit it, something a server with dozens of gigabytes of RAM would never notice.
The processing libraries also need to be downloaded on your first visit to a given tool, since there's no server doing that work on your behalf. We cache them aggressively in the browser, so it's a one-time cost per device rather than something you pay on every visit.
And browsers still can't do everything a native PDF library written in C++ can. Some obscure font formats, some less common encryption variants, and some edge cases in malformed or corrupted PDFs fall outside what pdf.js and pdf-lib handle today. They cover the overwhelming majority of real-world files, but not literally every one that's ever been produced. We're upfront about the gaps we know about, and we close them as the platform — and our own tools — mature.
Who This Matters Most For
Anyone handling a document they'd rather not hand to an unfamiliar third party benefits from local-first processing, but some situations make it matter more than others. A healthcare provider filling out a form that contains patient information is often bound by rules about where that data is allowed to travel, not only about whether it eventually gets deleted somewhere downstream. A lawyer or accountant routinely works with documents that are confidential or privileged by definition — a signed engagement letter, a set of exhibits, a client's return — where "we deleted it after processing, per our retention policy" isn't necessarily the standard the document needs to meet. A freelancer or small business without a dedicated IT or compliance function doesn't want to have to read and evaluate a vendor's data-retention policy just to merge two PDFs before a client call.
None of this requires the file in front of you to actually be sensitive for local-first to be the better default. It just means you never have to stop and ask which category your document falls into before deciding whether it's safe to use a given tool.
See for Yourself
You don't have to take our word for any of this. Open your browser's developer tools, switch to the Network tab, and use any OxygenPDF tool while it's open. You'll see the page's own JavaScript and WebAssembly files load once, and then nothing resembling your file: no request carrying its bytes, before the operation starts or after it finishes. If you want to be thorough about it, load the tool, disconnect from Wi-Fi, and process the file anyway. It'll work, because it was never talking to a server to begin with.
Frequently Asked Questions
Does OxygenPDF work offline?
Once a tool's page has loaded, yes. The operation itself doesn't need a network connection, since nothing about it gets sent anywhere. You do need a connection the first time you open a given tool, so your browser has something to download and cache.
Is client-side processing as secure as a server with encryption?
They solve different problems, so it's not really an apples-to-apples comparison. Server-side encryption protects a file while it sits on someone else's disk. Local-first processing removes the "someone else's disk" from the equation entirely — the file exists only in your browser's memory and on your own device, with nothing to encrypt on a server because nothing was ever stored on one. If you also want a password on the file you send to someone else afterward, Protect PDF adds that on top, still without ever uploading anything.
Is OCR still private?
By default, yes. OxygenPDF's Tesseract and PaddleOCR engines run in WebAssembly inside your own tab, and page images never leave your device with either one. If you explicitly pick one of the optional cloud OCR engines for a specific file, that file's page images are sent to a server for recognition; every other tool, and OCR on every other file, stays local regardless of that choice.
Is there a file size limit?
Not a hard one. The free web app shows a nudge toward the paid plan once a file passes 50MB, but it doesn't stop you from processing it. Your device's available memory is the actual constraint, and that varies by machine and by how many high-resolution images the PDF is carrying.
Why does the first tool I open feel slower than the ones after it?
The first tool you open has to download its processing libraries before it can do anything, since there's no server that already has them loaded and waiting. After that, your browser caches them, so reopening the same tool, or opening a different one that shares the same underlying libraries, starts instantly.
