You do not have to take my word for it

The three steps, without hand-waving

1. Read.

   You pick a file. The browser gives the page a File object — a handle to bytes on your disk. The tool reads those bytes into memory with arrayBuffer() or streams them. No network request is involved.

2. Transform.

   JavaScript or a WebAssembly engine does the work. pdf-lib builds a new PDF, pdf.js renders pages, ffmpeg.wasm encodes video, tesseract.js recognises text. The original bytes are treated as input; the original file on disk is never written to.

3. Save.

   The result is wrapped in a Blob, given a temporary blob: URL, and offered as a download. Your browser writes a new file wherever downloads go. The temporary URL is revoked when the page is done with it.

There is no fourth step where the file is —sent for processing—. That step does not exist in the code, which is why the site can work with the network cable unplugged.

The 30-second proof

This works in Chrome, Edge, Firefox and Safari, with slightly different menu names.

1. Open the tool you want to test.

   For example, Merge PDF or Compress Image. Let the page finish loading first.

2. Open DevTools and select the Network tab.

   Press F12, or right-click — Inspect — Network. Click the clear button (the circle with a slash) so the list starts empty. Leave —Preserve log— off.

3. Process a file.

   Drop a test file, press the button, let the result download. Watch the Network list.

4. Look at what appears.

   You will see the page—s own assets if they were not already cached — HTML, CSS, JavaScript, fonts, maybe a WebAssembly engine the first time. What you will not see is a request whose body is your file. The request list may be empty after the tool is loaded; that is the normal result.

If you want a stronger test, disconnect from the internet after the tool has loaded and process the file again. A tool that needed a server would fail. A local tool keeps working. This is also how the offline mode is tested.

What is actually running

All of these files are served from this domain, with one disclosed exception: the ffmpeg core used by video and audio tools is larger than Cloudflare Pages allows, so the pages.dev build fetches that single file from the project's own GitHub Pages mirror. There is no runtime CDN call, no remote font, and no third-party script that could observe the page. The about page lists the licences and credits.

What the service worker caches

On the first visit, the site registers a service worker. It stores a small app shell — the home page, category pages, CSS, JavaScript, fonts and the offline page — and then caches pages and engines as you use them. That is what makes a second visit work without a connection.

• Pages you have opened are cached and available offline.
• Processing engines are cached the first time a tool that needs them is used. A video tool may fetch a large WebAssembly file once.
• OCR language data is cached after the first run in that language.
• Your files are never cached. The service worker does not see the bytes you process; it only stores the site—s own assets.

A tool you have never opened may not work offline, because its engine was never downloaded. The offline page explains what to do when that happens. Clearing site data removes the cache; a private window generally starts with an empty one.

What does leave your device

Honesty is more useful than an absolute slogan, so here is the complete list:

• Page requests. Your browser asks the host for the HTML, CSS, JavaScript, fonts and engines. Those requests include ordinary HTTP data such as your IP address and user-agent. They do not include your files.
• Email you choose to send. The contact form opens a draft in your mail app. If you press Send, your email provider handles the message.
• External links you click. A guide may link to a standards body or an open-source project. Nothing is requested from that site until you click.

That is the whole list. There is no analytics beacon, no error-reporting service, no ad auction, no —anonymous usage statistics— and no file telemetry.

Why local processing has limits

The same architecture that makes the privacy claim true also explains the rough edges:

• Memory. A browser tab has a memory budget. A huge video or a 2,000-page PDF can exhaust it, even on a machine with plenty of RAM, because the browser sandbox is conservative.
• Speed. One CPU doing video encoding is slower than a rack of servers. For short clips the difference is small; for a feature film it is not.
• No office rendering. A faithful Word/Excel/PowerPoint — PDF conversion needs a full office engine. Running one properly in a tab is not realistic, so the tool is absent rather than fake.
• First-use downloads. Engines and OCR languages are fetched on demand. After that they are cached, but the first run needs a connection.
• Browser differences. Safari, Firefox and Chromium-based browsers enforce different memory and download rules. A job that works in one may need a different approach in another.

For a 4 GB video or a 5,000-page archive, a desktop application is the right tool. For the everyday documents this site was built for, the browser is enough — and the file never leaves the room.

Keep reading

The security page covers encryption, threat models and responsible disclosure. The privacy policy lists the exact local-storage keys and hosting-log caveat. The guide How browser-based file tools actually work goes deeper into the File API and WebAssembly.