How Browser-Based PDF Processing Works: What Happens to Your File
'Your file never leaves your device' is a claim you'll see on every privacy-first PDF tool, including this one. Most of them don't explain what that actually means or how to check it yourself. This article walks through exactly what happens between selecting a PDF and downloading the result — and how you can verify each step in under a minute, without trusting anyone's word for it.
The short version
When you use a browser-based tool like PDFcraft, your PDF is read into your browser's memory, processed there by JavaScript (and in a few cases, WebAssembly) running on your own device, and the result is packaged back into a file you download — all without a network request ever being made. No server sees the file, because no server is involved in handling it at all. The rest of this article breaks down each of those steps and shows you how to confirm it.
Step 1 — Selecting a file doesn't send anything anywhere
When you click 'Select File' or drag a PDF onto the page, your browser opens its own native file picker — the same one every app on your computer uses. Choosing a file there just gives the webpage a reference to that file sitting on your disk. Nothing is transmitted at this point. This is standard browser behavior (the File API), not something PDFcraft built — every website that lets you 'select a file' works this way before any code decides what to do with it next.
Step 2 — Reading the file into memory
Once a file is selected, PDFcraft calls a browser function that reads the file's bytes into your device's RAM, as a block of data called an ArrayBuffer. This is a local disk-read operation — conceptually similar to opening a file in a desktop app. It does not involve the internet. If your WiFi were off at this exact moment, this step would work identically.
Step 3 — Processing happens in your browser, not on a server
Most tools use pdf-lib
Merge, split, compress, rotate, watermark, delete pages, reorder, and page numbering all use a JavaScript library called pdf-lib, which reads and rewrites the PDF's internal structure directly in your browser's JavaScript engine — the same engine that runs the page itself.
Password protection and unlocking use WebAssembly
Protect PDF and Unlock PDF use a compiled version of qpdf (a well-established PDF encryption tool) running as WebAssembly — essentially native code executing inside a sandboxed area of your browser, which is why encryption is fast even on a phone.
Image conversion uses your browser's own rendering engine
PDF-to-image tools render each page using pdf.js (the same rendering engine behind Chrome's built-in PDF viewer) onto an HTML canvas, then read the resulting pixels back out as an image file.
Step 4 — The result is generated as an in-memory blob, not uploaded anywhere
The processed PDF comes out of these libraries as raw bytes, which get wrapped into something called a Blob — a browser-native container for file-like data. PDFcraft then calls URL.createObjectURL() on that blob, which creates a special local reference (it looks like blob:https://getpdfcraft.com/xxxxx) that only works inside your current browser tab. It is not a real internet address — you couldn't send that link to someone else and have it work on their device. It's essentially a name tag for a piece of memory sitting in your own browser.
Step 5 — Downloading is a local file save, not a server response
When you click Download, PDFcraft creates an invisible link pointing at that blob URL and clicks it programmatically, which triggers your browser's normal 'Save File' behavior — the same mechanism used to save any file from any website. The file is written from your browser's memory straight to your device's disk. No round trip to a server happens at this stage either, because there's no server response to wait for.
What happens when you close the tab
Blob URLs and everything they point to are scoped to the page that created them. When you close the tab or navigate away, the browser releases that memory — the in-progress file, the blob, all of it — the same way closing a document in a desktop app frees the memory it was using. PDFcraft doesn't write your file to any persistent browser storage (no localStorage, no IndexedDB, no cookies containing file data) — so there's nothing left over to find even if you wanted to.
How to verify this yourself — no technical background needed
Open your browser's Network tab
In Chrome, Firefox, or Edge, press F12 (or right-click → Inspect) and click the 'Network' tab. This shows every request your browser makes to the internet.
Use any PDFcraft tool
Upload a PDF and run any tool — compress, merge, whatever you like. Watch the Network tab while it processes.
Look for your file
You'll see the page's own assets load once at the start (the HTML, JavaScript, and CSS that make up the site). After that, while your PDF is being processed, you will not see any new request appear — because none is made. This is the same test any developer would run to check this kind of claim, and it takes about 30 seconds.
The honest limitations of this architecture
- Your device does the work, so processing speed depends on your device — a large PDF on an older phone will be slower than the same file on a laptop.
- There's no server-side fallback for very large or unusual files — if your browser runs out of memory on a huge PDF, the tab may become unresponsive rather than a server handling it gracefully. (We cover this in detail in our troubleshooting guide, linked below.)
- Because nothing is stored anywhere, there's no history or cloud backup of anything you've processed — if you close the tab before downloading, the result is gone and you'd need to start over.
- This architecture works for the kind of document editing PDFcraft does. It's not how every kind of software should work — some tasks genuinely need a server. It's simply the right tradeoff for a tool whose main promise is not seeing your files.
💡 Pro tip
You don't have to take any privacy-first tool's word for it. The Network-tab check above works on any site making similar claims — if you ever see a request fire off to an unfamiliar domain while a 'local' tool is 'processing' your file, that's worth investigating.
Related reading
Frequently asked questions
Does PDFcraft ever see my file?
No. There's no code path in PDFcraft that sends your file anywhere — processing happens entirely inside your browser using JavaScript and WebAssembly running on your own device.
Is this the same as 'processing in the cloud'?
No — cloud processing means your file is uploaded to a remote server, processed there, and sent back. Browser-based processing means the code runs on your device instead, and your file's bytes never leave it.
Why do some PDF tools require uploads and others don't?
Some processing genuinely requires more computing power than a browser can offer, or needs to combine data from multiple sources server-side. For the kinds of tasks PDFcraft offers — merging, splitting, compressing, converting, protecting — a browser is powerful enough to do the whole job locally.
Does this work without an internet connection?
Once the page itself has loaded, the actual PDF processing doesn't need a connection — it's all happening locally. Loading the page for the first time does require internet, the same as any website.
Can I check this without knowing how to code?
Yes — the Network tab test above is built into every major browser and just involves watching a list, not writing anything.
Try any PDFcraft tool and watch the Network tab yourself
Free, instant, private. No sign up required.
Try it free →