Architecture

Most PDF sites read your file
on their machine. This one cannot.

Not a setting, and not a promise in a policy — the same tool that merges or signs a PDF runs inside your browser, opening the file from your own disk. There is no upload step, so there is no copy of your document anywhere but the device you are holding.

Written for the person who has to say yes to a tool that touches client documents. The gaps are on this page, in the same place as the claim.

The difference

Same result on screen. A different legal object underneath.

The usual way

The file goes to their server

You pick a file, it is uploaded, their machine does the work, you download the result. Most PDF sites work this way, and it is why they can offer batch jobs and an admin console.

  • The document leaves your device and is stored, at least briefly, on someone else's disk
  • That someone is a processor of the personal data inside it
  • A processor has to be named in your records, assessed, and covered by a written agreement
  • Retention is a policy you have to read and trust, not a property of the software
This site

The file never leaves the tab

The page downloads a program, and that program opens the file from your own disk. Nothing is sent anywhere, because there is no upload step to send it through.

  • The document is read into the tab's memory and written back out to your downloads folder
  • No copy exists on any server at any point, including during the work
  • There is no retention period to review, because there is nothing retained
  • You can prove it: open the network panel and watch a file convert with no request carrying it
In the paperwork

What a reviewer can actually write down.

Four statements, each narrow enough to be checked rather than taken on trust.

There is no transfer of the document

A controller-to-processor relationship exists where personal data is transmitted to someone who processes it on the controller's behalf. For the document, that transmission does not happen. There is no recipient.

That removes one processor from the register

Not every processor — Stripe still handles card details, the mail relay still carries messages, and the host still writes an access log. But the one that would have held your client's contracts does not exist.

Data residency stops being a question for the file

A file processed in the tab has no region. There is no adequacy decision to check, no transfer mechanism to document, and no sub-processor list that has to be kept current for it.

It is architecture, not a promise

A policy says what a company intends to do. An architecture says what the software is capable of. This one has no upload endpoint, so a future change of intention would need new code, not a new paragraph.

Before you rely on it

What still leaves the device.

The claim is about the document, not about the site. These are the four places a careful reader will look, answered before they ask.

The payment is not private

Buying a pass sends your email and card details to Stripe, which is a regulated processor with its own terms. That is a normal card payment, and it is unrelated to the documents you process.

The pages themselves are logged

The site is served over HTTPS like any other, so the host records the request: an address, a time, a user agent. It does not record what you opened, because it never sees it.

There is no audit trail

Because nothing is centralised, there is no server-side log of who converted what. If a policy requires that evidence, this is the wrong tool and it says so here rather than in a support thread.

Batch work is bounded by your machine

The work happens on your hardware, so a very large document or a hundred-file batch is limited by the memory in the tab. A server-side service can accept more, because it is spending someone else's machine.

Trying to keep documents off other people's servers?

A seat band covers a small team today. For a named invoice, a signed DPA and the security questions in writing, the teams page reaches a person.