Data Processing.

This page explains, in technical but plain terms, exactly what happens when you process a document on PDFSamurai. We publish it because most users of online PDF tools have a vague idea that their file is sent somewhere — and we want the specifics of our architecture to be visible, not hidden in a privacy policy.

1. The chain of custody, step by step

Step 1 — Page load

You visit a tool page (for example, /merge-pdf/). Cloudflare serves the static HTML, CSS and JavaScript for that page from the nearest edge location. No information about you beyond the standard HTTP request data leaves your device.

Step 2 — File selection

You drag or pick one or more PDF files. The browser surfaces them to JavaScript via the File API. At this moment, the file's bytes are loaded into the memory of the browser tab you have open. They are not uploaded.

Step 3 — Processing

The tool you are using invokes the relevant open-source library — pdf-lib for page-level operations, pdf.js for rendering, and so on — which runs the operation inside that same tab. The result is a new Blob object, again in the tab's memory.

Step 4 — Download

The browser creates a temporary object URL pointing at that Blob and presents it to you as a download. The save is between your browser and your file system. We are not part of it.

Step 5 — Tab close

When you close the tab, the browser releases the memory holding your file. There is no cache, no temp file on the server (because no server received it), and no record of which file you processed.

2. What we can and cannot see

From our infrastructure provider's logs we can see the request data described in section 2.2 of the Privacy Policy — IP, user-agent, URL, timestamps. We cannot see filenames, file contents, page counts, passwords, or any metadata from your documents. If we received a subpoena demanding the contents of files processed on the Service, the honest reply is that they do not exist on our infrastructure to begin with.

3. Subprocessors

We rely on the following third parties for site delivery and operation:

• Cloudflare, Inc. — static hosting (Pages), edge delivery, DNS. Sees standard HTTP request data.
• GitHub, Inc. — source code repository for the site. No user data.
• Google LLC (AdSense) — only if you consent to advertising cookies, serves ads on your visit.
• Email provider — delivers email messages you send to us.

None of these subprocessors receives the contents of files you process through the tools, because we ourselves do not.

4. Edge cases

A small number of optional, advanced features (typically in future Pro tiers — for example, OCR over very large PDFs that outgrow browser memory, or e-signature workflows that require a cryptographic audit trail) may need server-side processing to be practical. Where that is the case, the tool page will make the switch explicit before any data is sent, and the relevant processing will be described here with retention periods. As of the date at the top of this page, no such server-side feature is in use.

5. Audit and verification

Because the entire site is delivered as static assets and client-side JavaScript, technically curious visitors can verify these claims directly:

• Open your browser's developer tools, switch to the Network tab, and inspect what is sent when you run a tool. You should see no upload of your file.
• Read the public source code in our repository, where the relevant processing functions live in /lib/pdf-engine.ts.

6. Questions

Technical or compliance questions on this page: privacy@pdfsamurai.co.uk.