How ZasPDF processes your documents without uploading them

This page describes the site's actual architecture: what code each tool runs, what stays on your device, what does leave it, and how to check all of it yourself in two minutes.

The model in one sentence

A conventional PDF service receives your file, processes it on its server and sends the result back. ZasPDF reverses the order: it downloads the program to your browser and runs the processing there. The file is never sent because there is nothing to send it to; the site is served as static pages from Cloudflare Pages and has no processing server to call.

This is not a policy we could break; it is a property of the design. If we wanted to see your files tomorrow we would have to build a server, change the site's code and start uploading them — and that change would be visible in the Network tab of any browser.

Which engine runs each tool

The structural PDF operations (merge, split, compress, reorganize, protect and unlock) are done by an engine written in Go on top of the open-source pdfcpu library, compiled to WebAssembly. It is a binary of roughly 20 MB (main.wasm) that the browser downloads on first use, caches permanently and executes inside the WebAssembly sandbox: no file-system access, no network access, only the memory the tab hands it.

The rest of the suite uses JavaScript libraries that also run on the client:

pdf.js (Mozilla's engine, the one Firefox uses) to render pages and extract text: PDF to image, PDF to text, previews.
tesseract.js for OCR: language models are downloaded to your browser and recognition happens in a local Web Worker.
pdf-lib for signing, watermarks, page numbers and annotations.
mammoth, docx, xlsx and pptxgenjs for conversions to and from Word, Excel and PowerPoint. They rebuild content rather than trace it, which explains their fidelity limits.
The scan tool uses the device camera through getUserMedia; the video never leaves the browser.

What exactly happens to your file

When you choose a file, the browser reads it into memory as a byte array and passes it to the engine. The engine produces another byte array with the result. That result becomes a Blob object and the download link points at it through a blob: URL local to the tab. When you close or reload the tab, both arrays are released. There is no disk cache, no temporary copy, no history of processed files. Nor can we see the file's name, size or contents: analytics only records that a tool was used (for example "merge"), and only if you accepted analytics in the cookie notice.

Passwords typed into Protect and Unlock follow the same path: they are handed to the engine in memory and vanish with the operation. The encryption Protect applies is AES-256 per the PDF 2.0 specification, the same Acrobat uses; the site does not keep the password and cannot recover it if you forget it.

What does leave your device (and why)

It would be dishonest to say the site makes no external connections. These are all of them:

Downloading the site and the engine from Cloudflare Pages, which logs IP address, user agent and time like any web server.
Google Analytics 4 (page views, approximate country, device type and the tool_used / file_downloaded events carrying the tool name). Only enabled if you accept analytics; it defaults to denied through Consent Mode v2.
Google AdSense, which funds the site. Without consent it serves non-personalised ads; with it, it may set advertising cookies.
Firebase Authentication, only if you choose to create an account. No tool requires one.
The contact form, which sends your message to our inbox through a Cloudflare function and the Resend service.
Google Fonts for the Material Symbols icons.

None of those connections carries your file. The privacy policy describes each one with its legal basis, retention and how to withdraw consent.

How to verify it yourself

We are not asking you to trust this page. Two checks anyone can run:

Network tab. Open your browser's developer tools (F12 or Cmd+Opt+I), go to “Network”, load a PDF into any tool and process it. You will see the initial download of main.wasm and the analytics or advertising requests if you accepted them; you will not see any POST request the size of your file.
Airplane mode. Load the tool, wait for the engine to finish downloading, disconnect from the network and process the file. Merge, split, compress, rotate, protect and unlock work exactly the same. If the file were being uploaded to a server, that would be impossible.

The one exception to offline use is OCR the first time a language is used: tesseract.js models are downloaded on demand and cached afterwards.

What this model does not solve

Processing locally removes the risk of your file leaking from someone else's server. It does not protect against a compromised device: if your machine has malware that reads browser memory or intercepts downloads, no website can prevent that. Nor does it replace a certified e-signature platform, provide a trusted timestamp, or encrypt the output file unless you use the Protect tool to do so.

And because your device sets the ceiling, a PDF of several hundred megabytes can exhaust the tab's memory, especially on mobile. The cloud alternatives page explains candidly when a server-based service is the better choice.

Site headers and isolation

Beyond the architecture, the site is served with HTTP headers that shrink the attack surface: Strict-Transport-Security (HTTPS only, for a year), X-Frame-Options: DENY (nobody can embed ZasPDF in an iframe to trick you), X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin and a Permissions-Policy that denies microphone, geolocation, payments and USB and limits the camera to our own origin for the scan tool. All of it is public in the response of any page.

If you find anything that contradicts what is described here, write to us through the contact page: security reports are answered with priority.