PDFConversionToolsAll tools

How browser-based PDF tools work

Written by Aurangzeb Khan. Last updated 17 August 2026.

When you use most PDF websites, your file makes a round trip. The browser sends it to a server, a program on that server does the work, and the result comes back down. That is a perfectly ordinary way to build a web application, and it is how iLovePDF, Smallpdf and Sejda all work. It also means your document spends time on a computer you do not control.

6 of the 6 tools here do not work that way. There is no round trip because there is no server involved in the processing at all.

What actually happens when you drop a file

Dropping a file on a web page does not upload it. It hands the page a reference to the file, and the page can then ask the browser to read the bytes into memory. That is a local read, the same as any program on your computer opening a file.

Once the bytes are in memory, the work is done by a PDF library that was downloaded along with the page, in the same way an image or a stylesheet is downloaded. That library is a program. The browser runs it. It parses the document structure, makes the changes you asked for, and serialises a new document back into memory.

The last step is a download. The page creates a temporary local address for the bytes it just produced and tells the browser to save them. That address exists only inside your browser and disappears when you close the tab.

Which library does what

pdf-lib handles anything that rewrites a document: merging, splitting, extracting and removing pages, rotation, page numbers, watermarks and encryption. It reads the PDF object structure and writes a new file from it. Because it copies page content across rather than re-rendering it, text stays selectable and images keep their original resolution.

PDF.js, the renderer Mozilla built for Firefox, draws pages to a canvas. Every thumbnail you see in the tools comes from it, and so does the page image when you convert a PDF to JPG. It is also what reads the text layer when a tool needs the words rather than the picture.

Both are open source and widely used, which matters. You are not being asked to trust a private implementation. Anyone can read what these libraries do, and thousands of people have.

Why the heavy work happens on a separate thread

Rewriting a large PDF takes real computation. If that ran on the same thread that draws the page, the interface would lock up and the browser would offer to kill the tab.

So it does not. Every operation runs in a Web Worker, a genuinely separate thread. The page sends the worker the file bytes and the options, the worker reports progress as it goes, and it sends the finished document back. That is why the progress bar moves smoothly and why the cancel button works instantly: cancelling terminates the thread.

How to check this yourself

Do not take this page's word for it. There are two straightforward ways to verify the claim.

Open your browser's developer tools and select the network tab before you use a tool. You will see the requests that load the page, its code and the PDF library. Then drop a file and run the tool. Nothing new appears. There is no request carrying your document because no such request is made.

Or test it the blunt way. Load a tool page, then turn off your wifi or unplug the network cable. Now use the tool. It works, because everything it needs is already on your machine. A site that uploads your file cannot do that.

What this does not cover

Being honest about the limits is the point of this page. Tools marked with an amber badge send your file to a server, and they say so in their first paragraph. Right now that badge applies to conversions that need a full office suite to produce a layout-faithful result, which is not something that runs sensibly in a browser.

Local processing also has real costs. The document is held in your device's memory, so a very large file on a phone can fail where a server with plenty of RAM would not. Browser-based OCR is slower than server OCR, because your laptop is slower than a rack of machines. Where a tool is slower or weaker than the server-based equivalent, its page says so rather than pretending otherwise.

What we store

For the browser-based tools, nothing, because nothing reaches us. There is no upload, so there is no file to retain, no retention period to describe and no deletion process to trust. Your original file on disk is never modified either. Every tool writes a new document and leaves the source alone.

Questions

How can a website edit a PDF without uploading it?

Browsers can run real programs. The PDF library is JavaScript and WebAssembly, so the browser executes it on your machine, reads the file you picked, and writes the new one there. The network is not involved.

How do I verify that my file is not uploaded?

Open your browser's developer tools, go to the network tab, and use a tool. You will see the page load and then no further requests while the work runs. You can also disconnect from the internet after the page loads and the tools will still work.

Which library does the work?

pdf-lib rewrites documents, meaning merging, splitting, rotating and page changes. PDF.js from Mozilla renders pages so you can see thumbnails and previews. Both are open source and both run inside your browser.

Is anything about my file recorded?

No. There is no upload, no file name logging and no analytics on what you process, because the code that handles your document runs on your device and never reports back.