"Your file is never uploaded" is an easy claim to make and a hard one to prove. This article explains, technically, how LocalPDF actually does it — and how you can verify it yourself.
Where the whole editing process actually happens
LocalPDF is a pure front-end application — when you open the page, your browser downloads a bundle of JavaScript, and everything from that point on runs inside your own browser process, in three stages:
- Parsing and rendering: the open-source library
pdf.js(maintained by Mozilla — it's the same engine that powers Firefox's built-in PDF viewer) reads the PDF's internal structure in your browser and draws each page onto a<canvas>element. - Editing: the text, highlights, images, and other edits you make only modify a data structure held in your browser's memory — no final file has been generated yet.
- Export: when you click "Download," another open-source library,
pdf-lib, reassembles the in-memory edits into a standard PDF file, which your browser's native download mechanism saves straight to your device — this step is also entirely local.
Why this means no upload is needed
Because none of the four steps above — parse, render, edit, export — rely on a server for computation. The server's only job is delivering the JavaScript code the first time you load the page; after that, it's not involved at all. Your PDF's actual content exists, from start to finish, only in your own computer's browser memory.
You can verify this yourself
- Open the LocalPDF page and press F12 (or right-click → Inspect) to open developer tools.
- Switch to the Network tab.
- Drop in a PDF, edit it, and download it.
- Watch the network panel — you'll see a handful of static asset requests when the page loads, but no request that sends your PDF's content anywhere.
- Go further: once the page has loaded, disconnect from the internet and repeat the same editing flow — it still works exactly the same.
Don't just take our word for it — open developer tools and check yourself.
Open LocalPDF →