Server-side PDF mergers see your documents. For contracts, medical forms, or unreleased designs, that data path is unacceptable even if the vendor promises encryption. PracticalKit’s PDF merge path uses pdf-lib in-tab: files are read via File API, merged into a new ArrayBuffer, and offered as download.
What actually leaves the device: only static assets (JS, WASM workers) load from our CDN. The PDF bytes stay in memory unless you save the result. Third-party analytics or ads, if enabled after consent, are separate from merge logic—see the privacy policy.
Limits you will hit: very large PDFs exhaust memory; encrypted PDFs need passwords pdf-lib cannot guess; complex forms and embedded JavaScript may flatten unexpectedly. Scanned books hundreds of megabytes should use desktop tools with streaming IO.
Step-by-step: open /pdf/, choose multiple files in order, merge, verify page count in a local viewer, keep originals until satisfied. For splitting and PNG export, the same page applies—each operation is independent, still client-side.
Compare to email-a-file services: browser merge reduces exposure but does not magically redact metadata. Use exiftool locally if XMP/author fields matter. Compare to CLI qpdf: CLI wins on automation; browser wins on zero install for occasional merges.
This article pairs with the PDF tool guide’s FAQ on memory and with the browser-first data handling post. Together they explain why we keep PDF in the flagship twelve after trimming forty-nine generic tools.
A compliance checklist helps teams: confirm the footer says in-browser processing; spot-check the network panel for absence of body uploads during merge; verify first, last, and critical chapter pages locally; retain source hashes alongside the merged output. Browser merge reduces vendor visibility; it does not erase device malware, shoulder surfing, or PDF metadata risks—those remain outside this tool’s scope and belong in your own controls.
2026-05-28