Proof, Not Promises
Every file tool on this site processes your documents on your own device — nothing is uploaded, ever. You don't have to believe us. This page shows you how to check, in about two minutes, with nothing but your browser.
Why "trust us" isn't good enough
Almost every online PDF service says it is "secure." What that usually means is: your file is uploaded to their server, processed there, stored for some period of time, and then — you are told — deleted. Every step of that sentence requires trust. You cannot see their servers, their logs, their staff, or their retention practices. If their promise is ever broken, you will be the last to know.
Quick Merge is built on a different architecture. The processing code — open-source JavaScript libraries like pdf-lib and pdf.js — is downloaded to your browser when the page loads. When you add a file, it is read into your device's memory and transformed right there. The finished result is handed back to you as a download from your own memory. At no point does file data travel over the internet, because there is no server-side processing step for it to travel to.
The difference matters: our privacy claim is a property of the architecture, not a paragraph in a policy. And properties of architecture can be verified by anyone. Here's how.
Verify it yourself: three tests
Watch the network tab
Open any tool page, then press F12 (or right-click → Inspect) and switch to the Network tab. Now add a file and run the tool.
You will see the page's assets load — scripts, fonts, styles — and you may see small analytics pings. What you will never see is a request carrying your file. A 20 MB PDF would be impossible to hide: an upload of that size would appear as a large, slow POST request. There isn't one.
The airplane-mode test
Load a tool page and wait for it to finish loading. Then disconnect from the internet entirely — turn on airplane mode or pull the network cable.
Now add your file and run the tool. It still works. Merging, splitting, converting — all of it completes with no connection at all, which is only possible if the processing happens on your device. A service that uploads files cannot pass this test.
Read the source
Right-click any tool page and choose View Page Source. The tool's logic is right there, unminified, in plain JavaScript — you can read exactly what happens to your file.
The libraries doing the heavy lifting (pdf-lib, pdf.js, jsPDF, heic2any) are widely used open-source projects whose code is publicly audited on GitHub. Nothing about the processing is hidden.
Exactly what does and doesn't leave your device
Honesty requires precision, so here is the complete picture — including the parts that involve the network. A normal web page cannot exist with zero network activity; the point is that none of that activity ever contains your files.
| Data | Leaves your device? | Details |
|---|---|---|
| Your files (PDFs, images, text you process) | Never | Read into local browser memory, processed there, downloaded from there. Cleared when you close or refresh the tab. |
| File contents, names, or metadata | Never | Not logged, not fingerprinted, not summarized, not sent in analytics events. |
| Page requests | Yes | Your browser fetches the page, scripts, fonts, and styles when it loads — like any website. This happens before you ever add a file. |
| Analytics | Yes | We use Google Analytics to count visits and see which tools are used. It never sees your files — only standard page-view data. You can block it with any ad blocker and every tool still works. |
| Advertising requests | Yes | Ads fund the free tools. Ad scripts load like on any ad-supported site and never have access to your file data. Blocking them does not affect the tools. |
If you want the strictest possible session: load the tool page, go offline (test 2 above), do your work, and close the tab. In that session, literally zero bytes left your device after page load.
The live indicator on every tool page
Every tool page shows a small shield indicator in the corner. It counts the files you've added and the bytes processed locally, and it contains a tripwire: it monitors the browser functions that could be used to upload data (fetch, XMLHttpRequest, sendBeacon) and flips to a red warning if any outbound request ever carries a file-sized payload.
It never will — but that's the point. The indicator exists so that the claim "0 uploaded" is being checked continuously, on your machine, by code you can read, rather than asserted once in a marketing page.
The open-source engines under the hood
- pdf-lib — creating, merging, splitting, and editing PDF documents entirely in JavaScript.
- pdf.js — Mozilla's PDF renderer (the same engine inside Firefox), used for reading and displaying PDF pages.
- jsPDF — generating PDFs from images and text.
- heic2any — converting iPhone HEIC photos, in the browser.
- JSZip — packaging multi-file results into ZIP archives locally.
Each of these projects is public, widely deployed, and independently maintained. We didn't invent client-side document processing — we committed to using it for everything, and to never quietly adding a server-side step.
Our commitments
- No file ever touches a server. If a future feature genuinely cannot run on-device, it will be a clearly labeled, opt-in, separate mode — never a silent fallback.
- No accounts required for the free tools. Anonymous use is a feature, not a limitation.
- No dark patterns. No fake countdowns, no artificial "2 tasks per day" walls, no watermarks held hostage.
- Plain-language honesty about what the site does load from the network (see the table above), and about each tool's real capabilities and limits.
Frequently Asked Questions
Modern browsers are powerful application platforms. When a tool page loads, it brings the processing code with it — open-source JavaScript libraries that can parse, edit, and rebuild PDF and image files. Your file is read into your device's memory with the browser's standard file APIs, transformed by that code, and offered back as a download. The server's only job was delivering the page itself.
Nowhere — they were only ever in your browser tab's memory, and that memory is released the moment the tab closes or reloads. There is no server-side copy to delete, no retention window, and no "your file will be removed after 2 hours" promise to trust, because nothing was stored in the first place. The downloaded result lives only where you saved it.
The architecture is the strongest available for confidentiality: your document is never disclosed to us or any third party, because it never leaves your device. For the most sensitive work, use the airplane-mode procedure — load the page, disconnect, process, close the tab — which guarantees zero network transmission during your session. As always, your own organization's policies govern what tools you may use; this page gives you the technical facts to make that assessment.
The free tools have to be paid for somehow, and today that's advertising — the same trade as most free websites. The privacy promise here is specifically about your files: analytics and ad scripts see standard page-view information, never your documents, file names, or file contents. Both can be blocked with any content blocker without breaking a single tool, and we are working toward funding models that need neither.
Client-side processing means your device does the work, so serving another user costs us almost nothing — no processing servers, no storage. That's why we can afford generous free tools funded by ads while services with expensive server farms need paywalls and daily limits. The economics and the privacy come from the same design decision.