Privacy

Files selected for processing are handled directly by your browser. We do not intentionally upload, store, or process the contents of your documents on our servers.

When you drop a PDF, your browser reads it with the File API and passes it to a Web Worker running on your machine. The result comes back as a Blob and your browser saves it to disk. There is no server step anywhere in that sequence, and there is no endpoint on this site that accepts a document.

Closing or refreshing the tool removes the active document unless the browser itself retains temporary data. We do not write your documents to local storage, IndexedDB, or a cache. There is no list of recent files, because there is nothing keeping one.

There are no accounts, so there is nothing for a document to be attached to.

Analytics must not include document names or document contents, so ours structurally cannot. The only events the code can produce are which tool was used and whether it succeeded - for example tool_started: compress_pdf.

File names, page counts, extracted text, metadata and passwords are not part of any event, and there is no field on an event that could carry them.

This is a website, so loading it makes ordinary network requests: the page itself, JavaScript, fonts, icons, and the PDF rendering engine. Those come from our own origin.

The site also carries advertising, which is what pays for it, and that does reach another company - Google - for the ad script and the ads themselves. What it is allowed to reach is written into the site’s Content-Security-Policy, which the browser enforces rather than us. Ads appear on pages and below the work, never beside an open document.

There is analytics too: which tool was opened, whether it finished, and roughly how long it took, in coarse buckets. It is served from this site rather than a third-party host, and it sets no cookie and no cross-site identifier. The events have no field for a file name, a page, a size or anything else taken from a document - not as a policy, but as a shape they cannot hold.

What none of those requests ever carry is your document. The thread that holds your file has its network functions removed outright - not by policy but in code, so a request from it throws - and no ad or analytics script is ever given a file name, a page, or anything derived from one. The promise is specific and deliberately narrow: your documents never leave your device. It is not a claim that the site makes no network requests at all.

The document processor runs in a Web Worker, and the first thing that worker does is remove fetch, XMLHttpRequest, WebSocket and the rest of the network APIs from its own global scope. If any code in that thread ever tried to open a connection, it would throw instead.

Advertising, when it exists, will be mounted only in a dedicated slot outside the processing workspace, so an ad script is never on the page while a document is open in a way that could reach it.