QuickMergeProof, Not Promises
Supported QuickMerge operations use local browser processing instead of a QuickMerge document-upload service. You do not have to take that claim on trust: this page shows how to inspect the specific workflow you intend to use with your browser's network tools.
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.
QuickMerge uses a different processing path for supported operations. The page downloads processing code — including open-source JavaScript libraries such as pdf-lib and pdf.js — and reads the selected file into browser memory. The result is created in the tab and offered as a download. Some tools also fetch engines or language data, so the defensible claim is specific: the selected file is not sent to a QuickMerge document-processing endpoint.
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 a tool page and choose View Page Source, then inspect the loaded scripts in Developer Tools. Production assets may be minified, but the network requests and browser-executed code remain inspectable.
The processing libraries (including pdf-lib, pdf.js, jsPDF and heic2any) are open-source projects with public source repositories. QuickMerge's own project repository is private, so this page does not present it as a public reproduction source.
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. |
For an offline check, first load the required processing code, disconnect and run the exact workflow. Inspect this page’s Network panel while testing. That check covers requests made by the page; it does not audit other applications, browser extensions or the operating system.
The live indicator on tool pages
Tool pages can show a shield indicator that counts files added and bytes handled locally. Its tripwire monitors common browser request functions (fetch, XMLHttpRequest, sendBeacon) and warns when an outbound request carries a file-sized payload.
The indicator is a useful check, not a formal security audit and not proof about browser paths it does not instrument. Use the Network panel procedure above for the exact tool and input you plan to use.
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.
And the part we can put numbers on
Privacy is the claim this page is about, and it is checkable in the network tab. Performance is the claim people ask about next, and it is checkable too — so we measured it rather than describing it. Every tool was run in Chromium, Firefox and WebKit against generated files at escalating sizes, and the results are published in full, including the ones that failed.
- Partial file size and performance measurements — completed results for the measured subset, with exact coverage stated on the page.
- Partial browser-support measurements — completed cross-engine runs for the measured subset, plus platform feature detections.
The completed raw records and fixture seed are public in measurements.json. The harness source remains in the private project repository, so visitors cannot currently reproduce the run from public source code.
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.
Local processing can reduce document exposure by avoiding a QuickMerge document upload for supported operations. That is not a guarantee of regulatory compliance or complete security. For sensitive work, load the required code, disconnect, run the exact workflow, and verify that it still functions; your organization's policies still govern which tools and devices may be used.
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.