Why local?

What actually happens when you upload a file

You pick a PDF. It travels over the network to a machine you do not control, is written to disk so a worker process can open it, is processed, and the result is written somewhere you can download it from. Then a retention policy — "files deleted after two hours" — says all of that will be cleaned up.

That policy is almost certainly honoured. But notice what kind of statement it is: unverifiable from outside. You cannot check whether a copy lingered in a backup, whether a crash dump caught the buffer, whether a log recorded the filename, or whether a subcontractor's storage bucket was public that week. The promise may be sincere and still be worth nothing to you, because you have no way to audit it.

The difference is architecture, not policy

Here, your PDF is processed in this browser tab and never uploaded. The code that reads it is JavaScript that your browser downloaded and runs in a Web Worker on your own machine. There is no upload step to audit, because there is no server-side processing to upload to. A file that never left cannot be retained past a stated window, cannot be intercepted in transit, and cannot appear in someone else's breach disclosure.

How to check this yourself

You do not have to take this page's word for it. A desktop browser can show you what the site sends:

1. Open a tool, for example Merge PDF.
2. Open the developer tools (F12, or Cmd+Option+I on a Mac) and switch to the Network tab. In Safari, first turn on the developer features in Safari > Settings > Advanced. Turn on "Preserve log" if your browser offers it.
3. Choose a PDF and run the tool all the way to the download.
4. Look through the list. You will see the site's own pages, scripts, styles and icons being fetched. None of those requests carries your file: none of them uploads anything the size of your PDF.

Every tool page also carries a request-body observer for window fetch, XMLHttpRequest and sendBeacon calls made after observation starts. It distinguishes measured sizes, multipart value lower bounds and unknowns. These are attempted calls; the counter does not establish delivery, total network bytes or complete processing privacy. Workers, service workers, other browser APIs, URLs (including query strings) and headers are outside it, which is why the network tab is the check that counts.

The honest exception

Not everything can be local, and a page like this is worthless if it overclaims. If we later add accounts and paid plans, sign-in and billing will need a server — that is unavoidable, because an account is server-side state by definition. What will never happen is file content going to it. The boundary is between account state and file data, and only the first one can ever leave your device.

Today there are no accounts, no analytics scripts and no third-party scripts on this site at all, so the question is moot. When that changes, this page changes with it.

The side effects are the good part

What it costs you

Your device does the work, so your device sets the limits. A phone has far less headroom than a laptop, and on iPhone and iPad a tab that runs out of memory can be closed without warning. Rather than let that happen, every tool checks the file size before reading it and refuses politely above the threshold. Each PDF can be up to 32 MB (25 MB on iPhone and iPad), and Merge combines up to 32 MB in total. The figure for the device you are using is shown in the file selector once the page has loaded.

This version has limits of its own too: Protect writes AES-128, not AES-256; Split makes one PDF at a time; and files with forms, bookmarks or digital signatures are refused. They are listed plainly on the tools page rather than quietly omitted.