When you search "merge PDF" on Google, the first page is dominated by tools that promise free, instant merging. Most of them work. Most of them also upload your PDFs to a server you've never heard of, owned by a company you can't quickly identify, located in a jurisdiction you didn't choose.
For a meme, that's fine. For a tax bundle, a signed contract, a medical referral, a litigation packet, or anything containing a Social Security number, account number, or trade secret — it's not.
This article is what we found when we audited the most popular online PDF mergers. The methodology is something you can replicate in five minutes per site. The conclusions might change which tool you use the next time you reach for "merge PDF."
How we tested
For each of the top 10 PDF merger search results, we ran the same procedure:
- Loaded the page in a fresh browser profile (no cookies, no history).
- Opened DevTools → Network tab, set the filter to "All".
- Cleared the network log.
- Selected two small PDFs (test documents we generated for this purpose).
- Clicked the merge button.
- Watched what happened on the network.
The signal we were looking for: does the request that initiates the merge contain the file's contents? If yes, the file went to a server. If no, the merge happened in the browser.
We're not naming the specific sites in this article — we don't want to dunk on any one operator, and the patterns we found are common across the category. But you can run the same test on whatever tool you use, and the answer will be one of the patterns below.
What we found
8 of 10 sites uploaded the PDFs to a server. Specifically, they made a multipart/form-data POST request to their own backend (or to a third-party file-storage API), where the contents of both PDFs were attached as form fields. The merged result was returned as a download from the same server.
For these sites, the privacy policies typically said one of three things:
- "Files are automatically deleted within 1 hour."
- "Files are stored only as long as necessary to complete your conversion."
- "We do not access the contents of your files."
The first two are factually narrow — your file is on the server long enough for a backup snapshot, an indexer, or a subpoena. The third is a process commitment, not a technical guarantee — "we don't access" doesn't mean "we can't access."
1 of 10 sites had a hybrid flow. The merge logic ran in the browser for files under 50 MB; larger files fell back to a server upload. This is reasonable from an engineering standpoint, but the disclosure was in their FAQ, not on the page itself. Most users wouldn't know which path their merge took.
1 of 10 sites was fully client-side. The merge happened entirely in JavaScript using pdf-lib, a popular open-source PDF library. The DevTools network log showed zero requests carrying file content during merge. The same library is what we use for ForgeMyFile's PDF tools.
Why this matters more than it sounds
The most common response to "your PDF was uploaded to a server you don't control" is "so what — the file goes back to me anyway." This is fine for low-stakes documents. The risks accumulate when the document contains:
- Personal identifiers. Names, dates of birth, SSNs, account numbers, employer info. The merger's database is now a target for breach disclosure.
- Financial data. Tax returns, brokerage statements, mortgage applications. The signal-to-noise ratio for attackers is high.
- Health records. Even a single line with a diagnosis or medication can trigger HIPAA exposure if the merger is a covered entity in your jurisdiction (and most are not).
- Legal documents. Discovery responses, NDAs, sealed court filings. Once it's on someone else's server, your privilege chain may have a gap.
- Trade secrets. Pricing sheets, customer lists, unreleased product specs. Even an automated indexer that touches the file is a leak you can't undo.
The threat model isn't just "the operator is malicious." It's "the operator gets compromised, sells the company, gets compelled by a subpoena, has a misconfigured S3 bucket, or deletes 'within 1 hour' but the deletion script has a bug." Your file just needs to be on the server long enough for one of these to happen.
How to verify a merger is local before you trust it
You don't need to take any operator's word for it. Run this test on whatever PDF merger you use:
- Open the merger's page.
- Open DevTools (F12 or right-click → Inspect) → Network tab.
- Clear the network log (the 🚫-with-circle button).
- Select your PDFs and click Merge.
- Look at the new requests. Specifically:
- Are there POST or PUT requests with Content-Type: multipart/form-data or application/octet-stream? - Click each request → Headers → look at "Request Payload." Does it contain your filename or the file's bytes? - If yes → server-side. If no → client-side.
A second, simpler test: disconnect your Wi-Fi after the page loads, then try merging. If it still works offline, it's local. If it fails, it's server-side.
What "local PDF merge" looks like under the hood
For the curious: the JavaScript library pdf-lib can read, modify, and write PDFs entirely in the browser. The merge operation is short — load both PDFs into memory, copy each page into a new document, save the result as a Blob, hand the Blob to a download. Everything happens in your browser tab; no fetch() call ever leaves the device with your file content.
pdf-lib is open-source under MIT license. You can read the entire merge logic in a few hundred lines of JS. There's nothing magical about it; it just hasn't been widely adopted because most "PDF merge" sites were built before the library existed and nobody rewrote them.
What to use instead
Any merger that meets the DevTools test is fine — it doesn't have to be ours. The criteria:
- Zero file-content network requests when you click Merge.
- Works with the network disconnected after first page load.
- The conversion library is identifiable (you can see it in the page source).
- Reasonable file-size handling — local mergers are bounded by your device's RAM, typically 2-4 GB, which covers basically any real-world PDF stack.
Specifically: ForgeMyFile's PDF merge does this. So do a small handful of others. If the tool you use doesn't pass the DevTools test, the cost of switching is one bookmark.
The general principle
Online file converters are one of the last categories of web tools where "the file goes to a server" is still the default, despite the technical fact that almost all of them could run in the browser. That gap is mostly inertia. The libraries exist; the browser APIs exist; the demos work. The only thing that changes when a category shifts to local-first is which operator handles your file — and "no operator" is strictly safer than "an operator."
If you read PDF merger privacy policies for an afternoon, you start to notice the same shape: assurances about handling, retention, and access. Those assurances are real but bounded. The unbounded version of the assurance is "your file is never on a server." That sentence is technically possible to write today. It's worth using a tool that can write it.
Need a privacy-first file converter? All 13 ForgeMyFile tools run entirely in your browser — files never leave your device.