100% in-browser processing
How FixMyPDFs works: right in your browser
Most PDF websites upload your file to their servers to work on it. FixMyPDFs does the work inside your browser tab instead, so the document never leaves your device. Here is what happens, in plain words — and how to check it yourself.
By Suprabhat Updated How we write these
- 0 BUploaded
- 0Accounts needed
- 100%On your device
- $0No ads, no paywall
In one picture
What happens to your file
- You pick a PDF. The page reads it from your disk into this tab’s memory — the same thing a PDF viewer does when it opens a file.
- The tool runs here. Code the page already downloaded — pdf.js, pdf-lib and WebAssembly engines — works on that copy, using your device’s own processor.
- You save the result. The finished file is handed to your browser as a normal download. Close the tab and the copy in memory is gone.
Our server only sends the page and its tools. The tools have no way to send your file back to it — the counter on the cut line reads what this page has actually sent.
Side by side
The upload way vs the FixMyPDFs way
The same job — say, taking two pages out of a signed contract — done the usual way, and done here.
A typical online PDF tool
Upload, wait, download
- Your file travels to their server. The whole document — contract, tax form, ID — is sent over the internet before anything happens to it.
- It waits its turn. Your job joins everyone else’s on the service’s machines, and a busy hour or a free-tier limit slows it down.
- A copy sits on their disk. It is kept until their policy says to delete it. You have to trust that it is, and that nobody reads it first.
- You download it back. The result comes back over the same connection, so a slow or metered line pays twice.
The document has left your hands, and the speed depends on your upload connection.
FixMyPDFs
Open, fix, save — on your device
- Your file is opened in this tab. It is read from your disk into the browser’s memory, like any PDF viewer opening it. No connection is made to send it.
- Your processor does the work. The engine for the job — pdf-lib, pdf.js, qpdf or another WebAssembly build — runs on your device, with no queue.
- Nothing is kept anywhere. There is no server copy to delete. The only copy is the one in this tab’s memory, gone when you close it.
- You save it straight away. The finished file is handed to your browser as a download: no round trip, however slow your connection.
The document never leaves your device, and the speed depends on your device.
Live test, not a simulation
Try it on your own device
Press the button. This page builds a 24-page PDF of photos in memory, then merges it with a copy of itself — the work Merge PDF does — and times it. Nothing is sent anywhere.
Measured in this tab, on your processor
Estimate: the same files sent at 10 Mbps, before a server has started on them
The device time is measured when you press the button. The upload time is worked out from the files’ real size and a 10 Mbps upload speed — yours may be faster or slower.
Behind the curtain
What happens, step by step
No jargon: this is what the three steps look like on the screen, and what each one does with your file.
-
Drop your PDF
Or pick it from your disk. There’s no size cap and no waiting line, because it never leaves your device.
-
Pick the fix
A size limit, a format, a password or the pages to keep. Presets for Gmail, job portals and government forms fill in the numbers for you.
-
Save it back
The fixed PDF lands in your downloads and the original stays exactly where it was, because it never went anywhere.
Your files never touch a server Every step above runs in this browser tab. Watch the network log to see it.
The pipeline
- 1
Read. When you drop a PDF, the page reads its bytes with the File API. The file stays on your disk; the tab holds a copy in memory.
- 2
Inspect. The tool checks what it’s working with: page count, encryption, whether pages have a text layer, form fields, embedded images.
- 3
Process. The engine for the job runs — in a Web Worker where the work is heavy, so the page stays responsive.
- 4
Save. The result is built as a Blob in memory and offered as a normal download. Closing the tab discards everything.
The engines
| Engine | What it does | Used by |
|---|---|---|
| pdf-lib | Reads and rewrites PDF structure: pages, fonts, forms, annotations, metadata | Merge, split, organize, stamp, sign, fill, flatten, create |
| pdf.js | Firefox’s PDF engine: renders pages and extracts text with positions | Previews, PDF to JPG, text extraction, redaction, conversions |
| qpdf (WebAssembly) | The reference implementation of PDF encryption and structure repair | Password protect, remove password, unlock, repair |
| Tesseract (WebAssembly) | An LSTM neural network that reads text from page images | OCR, scanned PDF to Word |
| Kokoro (ONNX Runtime) | An open neural voice model that turns text into speech | PDF to Audio, including MP3 saving |
| Your browser’s image codecs | Decode and re-encode the photos inside PDFs | Compress, images to PDF, extract images |
| Your browser’s layout engine | Lays out HTML, Markdown and Word content, which we then write as real PDF text | Word, HTML, Markdown, CSV and eBook to PDF |
What follows from the design
Built on four privacy principles
-
Nothing to retain
We cannot keep, read or share your files, because they never reach us. There is no upload endpoint on the site at all.
-
Works offline
A service worker keeps the pages and engines you’ve used, so a tool you’ve opened once works with no connection at all.
Using it offline -
No accounts
No email address, no password, no card. You arrive, fix the PDF and leave; there is nothing to sign up for.
-
Check it yourself
Open your browser’s Network tab while a tool runs and watch: the page downloads its code, and sends none of your file.
How to check
Why a Web Worker?
JavaScript on a page runs on one thread, shared with scrolling and clicks. Encrypting a 200-page PDF or reading a scan with OCR can take a few seconds of solid computation, so those engines run in a Web Worker — a second thread — and report progress back. The page never freezes, and the Cancel button always works.
What “0 bytes uploaded” means precisely
The page makes network requests for its own code and, the first time, for engines like qpdf or the OCR model. Those are downloads. The privacy meter in the header wraps every way a page can send data — fetch, XMLHttpRequest, sendBeacon and WebSockets, in the page and its workers — and counts the bytes that leave. For your files, it stays at 0. Check it yourself.
Ready to fix a PDF?
Pick a tool and watch the counter stay at zero while it works.
Questions
Which browsers does it work in?
Current Chrome, Edge, Firefox and Safari on desktop and mobile. Everything needs JavaScript and WebAssembly, which every browser from the last five years supports.
Why is the first run of some tools slower?
A few tools download an engine the first time: qpdf (2 MB) for passwords and repairs, the OCR model (11 MB), fonts for PDFs we write, and the reading voice for PDF to Audio (93 MB, from Hugging Face). After that they load from your browser’s cache, offline included.
How big a PDF can it handle?
As big as your device’s memory allows. A laptop comfortably handles PDFs of several hundred MB; phones have less room, so very large files are better done on a computer.
Can I use it for confidential tax, medical or legal files?
That is what it is built for: the file is never sent anywhere, so there is no copy on someone else’s server to leak or be requested. If your employer has rules about which software may open client files, those rules still apply — the difference here is that nothing leaves the device.
If nothing is uploaded, how is the site paid for?
The site is static files, and your device does the work, so it costs very little to run. There are no ads and nothing is sold; it is paid for by the person who runs it. If that ever changes, the About page will say so plainly.
Is the code open source?
The libraries doing the work all are, and are listed on the licenses page with what each one does here.