Are browser-based PDF tools really private?

What “browser-based” actually means

When you pick a file in a web page, the browser does not upload it. It hands the page a File object through the File API: a handle to bytes that already exist on your disk. The page can read those bytes into memory and do whatever it likes with them. Sending them to a server is a separate, explicit act — the page has to build a network request and transmit the data on purpose.

A conventional PDF site uploads your file, runs an engine on a server, and sends a result back. Your document leaves your machine, lands on a disk somewhere, and you are relying on a retention policy you cannot inspect. A browser-based tool skips all of that, because the work happens in the JavaScript engine already running on your own computer.

But the File API only makes local processing possible; it does not make uploading impossible. A page that reads your file locally and then also posts it to a server is perfectly ordinary HTML. That is why the rest of this article is about checking rather than trusting.

How it works on iBuildPDF

Every tool on the site follows the same four steps.

1. Read. Your selected file is read into an ArrayBuffer — a block of raw bytes in the tab’s memory.
2. Parse or render. Structural work (merging, splitting, rotating, editing metadata, stamping watermarks, writing page numbers) is done with pdf-lib 1.17.1, which parses the PDF object graph and writes a new document. Anything that needs to see a page as pixels (page thumbnails, image export, rasterising) uses Mozilla PDF.js 3.11.174 to draw the page to a canvas.
3. Produce. The finished document is serialised to bytes and wrapped in a Blob — still just memory inside the tab.
4. Download. The page calls URL.createObjectURL() on that Blob, which creates a blob: URL pointing at the in-memory data, and triggers a download from it. A blob: URL never touches the network; it is a reference to something the tab already holds.

Both libraries are loaded from a public CDN at those pinned versions. That is a network request and you will see it — but it happens when the page loads, it fetches JavaScript, and it carries nothing of yours.

No account is needed for any of this. Accounts exist only for conveniences like favourites and recent tools, and signing in changes nothing about where your file is processed.

How to verify it yourself

Do not take this on faith. Two checks settle it, and neither requires any technical background beyond following the steps.

Check one: watch the network

Open any tool — compress a PDF or merge PDFs will do. Press F12 (or Cmd+Option+I on a Mac) to open developer tools and select the Network tab. Tick Preserve log so nothing is cleared, then reload the page.

You will see the initial load: the HTML document, CSS, the site’s own JavaScript, and the CDN requests for pdf-lib and pdf.js. Now click the clear button to empty the list, and only then choose your file and run the tool.

What you should see after processing completes is nothing, or near enough. No request appears whose size is anything like your document’s. If any request did appear, you could click it and read its Payload tab to see exactly what was sent. The download itself will not show up as a server request at all, because it comes from a blob: URL.

A useful sanity check: note your file’s size, then sort the Network panel by its Size column. An upload would be impossible to hide there.

Check two: pull the plug

This is the stronger test, because it does not depend on interpreting anything. Load the tool page and wait for it to finish loading completely. Then turn off your Wi-Fi, or set the Network panel’s throttling dropdown to Offline.

Now use the tool. Pick a file, process it, download the result. It works. A tool that needed a server could not have produced that file, because there was no server to reach.

The only thing you must get right is the order: the libraries have to be in the browser cache before you go offline, since they are fetched at page load. Load first, disconnect second, process third.

What this does not protect you from

Local processing is a real property with real boundaries. Four of them matter.

• It is a property of the implementation, not of browsers. Nothing in the web platform stops a page from uploading a file it has read. “It runs in the browser” is a claim about what a particular site’s JavaScript does, and the only reason to believe it is that you checked — which is why the section above exists.
• Usage analytics are not file contents. The site may record that a tool was used. It does not record the file, its name, its size or anything drawn from it, because that data never reaches the page’s analytics layer in the first place.
• Your device is the trust boundary. A browser extension with permission to read page content, or a compromised machine, sits inside that boundary, and no web page can do anything about either. If a document is sensitive enough to worry about, the state of the machine you open it on matters more than the site you open it in.
• Memory is the ceiling. Because everything happens in one browser tab, very large documents are constrained by available RAM rather than by an upload limit. We cover where that line actually falls in how large a PDF a browser can handle.

When a server is genuinely required

Some jobs cannot honestly be done in a tab. Converting a PDF into an editable Word, Excel or PowerPoint file means reconstructing a document model — paragraphs, styles, tables — from a format that only records where marks go on a page. That needs layout-analysis engines which do not exist as browser JavaScript. Optical character recognition is the same story. iBuildPDF does not do OCR at all; there is no such tool on the site.

If a file goes to a server, its journey changes shape. It is transmitted, written to storage, read by a worker process, and held until something deletes it. Each stage is a place where a copy can outlive your expectations, and none of them is visible to you.

iBuildPDF’s PDF↔Word, PDF↔Excel and PDF↔PowerPoint converters are listed as coming soon and are switched off. That is deliberate: a converter that cannot run locally is not quietly shipped with an upload behind it. When those tools are turned on, they will be server-dependent, and the page will say so.

Everything else — all 31 live tools, including redaction, metadata removal and text extraction — runs locally today. The full technical detail is on the file privacy reference page.