How it works

The short version

1. Choose locally. You pick a file with your browser's file picker, drag-and-drop, or paste. The file is read with the browser's File API into memory in your tab.
2. Edit locally. The processing engine for that tool — canvas code for images, a PDF engine, a spreadsheet parser, or your browser's own media encoder — runs as JavaScript and WebAssembly in the same tab. There is no upload step, because there is no server that handles files.
3. Verify. Before a privacy-relevant result is offered for download, the tool reopens or rescans its own output and reports one of three statuses: Verified, Verified with declared limitations, or Failed verification. A failed check blocks the normal download.
4. Download. The output exists as a blob of bytes in your tab's memory. The download link points at that in-memory blob, not at a server URL.
5. Cleanup. Clearing a file or leaving the page releases the in-memory copies. Nothing about your file is written to our infrastructure, because it never arrived there.

What “local processing” means technically

This site is a static website. When you open a tool page, your browser downloads the page and the tool's processing code — the same way it downloads any website's assets. From that point on, the work happens in your tab:

• File access: the File and FileReader browser APIs read the file you chose into your tab's memory. Browsers do not send files anywhere when you do this.
• Processing: images are decoded and re-encoded with the canvas APIs; PDFs are parsed and rebuilt by a PDF engine running in your tab; spreadsheets are unpacked by a parser in your tab; video and audio are re-encoded by the encoder built into your browser. Engines load on demand when you open a tool, and only then.
• Output: results are assembled as a Blob in memory and downloaded via an object URL — a pointer to memory in your own browser, not a link to a server.

There is no upload endpoint in this application. That is not a policy promise that could be quietly broken by a config change — the deployed site has no server-side code that receives files at all.

Verify it yourself

The strongest privacy claim is one you can check. Here is how, in any modern browser:

1. Open a tool page — for example the image compressor or PDF merger.
2. Open your browser's developer tools (usually F12 or Cmd/Ctrl+Shift+I) and switch to the Network panel.
3. Optionally click the “clear” icon so the panel is empty, then select a file in the tool and run it end to end, including the download.
4. Watch the request list. You will see the page's own assets — script chunks, fonts, styles — load once. You will not see a request whose payload contains your file's bytes, your filename, or the output. Processing a 50 MB video produces the same network activity as processing nothing.

One important distinction: the application does use the network to fetch its own code. A tool's engine chunk may download when you open the page or click into the tool. Those are application assets — identical for every visitor — and they flow to your browser. Your file would have to flow from your browser, as a request body. You can click any request in the Network panel and inspect its request payload to confirm none carries your data.

What does use the network

What never uses the network

• Your file's bytes, before or after processing
• Your filename or file path
• Text, cells, pixels, or frames derived from your file
• Metadata values read from your file
• The output you download

There are currently no analytics scripts on this site at all, and tool pages carry no third-party scripts. The full details are in the privacy policy and the security and architecture page.