Skip to content

What “processed in your browser” really means

Which parts of a browser-based tool touch the network, which do not, and how to check for yourself in DevTools.

Last reviewed 8 September 2026

Plenty of sites promise that your files are processed “locally” or that your data “never leaves your device”. The claim is often true and almost always incomplete, because it describes one part of what happens when you open a web page and stays quiet about the rest. Here is what the phrase actually covers, what it does not, and how to check any site’s version of it in about thirty seconds.

What actually happens when a tool runs in the page

A browser can read a file you choose without sending it anywhere. When you drop a PDF onto a page, the browser hands the page the file’s bytes in memory. JavaScript running in that page can then parse the document, change it and produce a new file for download, all without a single network request carrying your content.

That is genuinely different from the usual model, where the file is uploaded to a server, processed there and sent back. In the upload model your document exists, however briefly, on somebody else’s infrastructure. It appears in their logs. It may be written to temporary storage, backed up, retained by a subprocessor, or handed over in response to a legal request. None of that is possible for a file that was never transmitted.

What the claim does not cover

The processing being local does not make the visit private. Four things remain true regardless.

  • The page itself came from a server. Loading it reveals your IP address, the page you requested and your user agent to the host and its network. That happens before any tool runs.
  • Analytics and advertising still work normally. If a site runs either, they operate whatever the tool does with your file. They see the visit, not the file, and that is still information about you.
  • Some tools download an engine. Browser-based video processing and text recognition need large WebAssembly builds that are usually fetched from a public CDN. Your file is not uploaded, but the CDN learns your IP address and what you asked for, which is enough to infer which tool you were about to use.
  • Your own device is still your own problem. Local processing protects a file in transit and at rest on a server. It does nothing about malware, a shared computer, browser extensions with permission to read page content, or clipboard history.

How to verify it yourself

You do not have to take anyone’s word for this, including ours.

  1. Open the tool page and press F12 to open developer tools.
  2. Go to the Network tab and clear the existing entries.
  3. Add your file and run the tool.
  4. Watch what appears. Sort by size. If your 12 MB PDF were being uploaded, you would see a request of roughly that size leaving the page.

On a tool that genuinely runs in the page you will see no request carrying your file. You may well see other requests — analytics, fonts, an engine download — and that is exactly the point: the Network tab shows you the difference between “no upload” and “no traffic”, which are not the same claim.

How this applies here

On this site, the PDF, image, text, developer and calculator tools make no network request of their own. Three cases are different, and each says so on its own page:

  • The video trimmer, audio converter and GIF maker download the FFmpeg engine, roughly 30 MB, from a public CDN the first time you start an operation.
  • OCR for PDFs downloads a recognition engine and English language data on first use.
  • Device Info asks this site’s own server for your public IP address, because a browser cannot know it.

The site also runs analytics and advertising, both gated behind the consent banner, and both described in the privacy policy. Saying that alongside the no-upload claim is the honest version of the same statement.

What to ask of any tool you use

If a site’s privacy claim is a slogan rather than a description, treat it as marketing. A trustworthy version names the exception. Look for three things: a clear statement of which tools contact the network, an explanation of what is stored and for how long, and ideally source code you could inspect. A page that promises to be “100% secure” without ever explaining what it does is telling you less than it appears to.

Tools referred to in this guide