—It runs in your browser— is used so often that it has almost stopped meaning anything. Some sites mean the interface runs in the browser while the file goes to a server. Others mean the entire transformation happens in the tab. The difference is not marketing; it is a specific set of browser APIs, and it is testable.

Here is what actually happens when a file tool is local, in the order the browser does it.

The File object is a handle, not an upload

When you choose a file with <input type="file"> or drop it on a page, the browser gives JavaScript a File object. That object is a handle to the bytes on your disk, plus metadata such as the name, MIME type and last-modified date. It is not the file—s contents copied into a request.

The page can ask for those bytes with file.arrayBuffer(), file.text() or a stream. At that moment the bytes enter the page—s memory. They are still local. No network request is involved unless the code explicitly makes one.

This is the same API that powers every upload button on the web. The difference is what the next line of code does with the bytes.

From bytes to result

A local tool has three stages:

  1. Read. The file becomes an ArrayBuffer, a Uint8Array, or a stream. For a PDF, a library parses the object structure. For an image, the browser—s decoder or a library reads the pixels. For a video, ffmpeg reads the container and frames.
  2. Transform. The engine does the work. It might be plain JavaScript, a Web Worker, or WebAssembly. A worker keeps the interface responsive while a large job runs; WebAssembly gives near-native speed for code originally written in C or C++.
  3. Save. The result is wrapped in a Blob, a browser object that represents immutable binary data. The page creates a temporary blob: URL and triggers a download. The URL points into the page—s own memory, not to a remote server. When the page is done, it can revoke the URL.

There is no hidden fourth stage. If the code never calls fetch() with the file, the file never travels.

What WebAssembly changes — and what it does not

WebAssembly (Wasm) is a compact binary format that browsers can execute at near-native speed. It is what makes it possible to run ffmpeg, a PDF renderer, or an OCR engine in a tab without shipping a desktop app. The engine is compiled to Wasm, downloaded by the page, and run inside the browser—s sandbox.

Wasm changes performance, not the privacy model. A Wasm module is still code running in your browser. It can read the memory the page gives it, and it can make network requests only if the JavaScript around it does. It does not get special access to your disk or your other tabs.

The sandbox is also the limit: a Wasm engine cannot use all the RAM on your machine, cannot spawn unlimited threads, and cannot run forever without the browser noticing. That is why a 4 GB video is a bad fit for a browser tab even on a powerful computer.

The Network-tab test, step by step

  1. Open the tool and let the page finish loading.
  2. Press F12 (or right-click — Inspect), then select the Network tab.
  3. Click the clear button so the request list is empty.
  4. Process a test file. Watch the list while it runs.
  5. Look for a request whose body is the file. On a local tool, there isn—t one. You may see the page—s own assets if they were not already cached, and a Wasm engine on first use.

The test is not perfect: a malicious page could disguise a request, and the Network tab does not show everything a service worker does. But it is a strong signal, and it is far better than a badge. Combine it with the offline test below for a second angle.

The offline test is the second proof

Load the tool, then disconnect from the internet and process the same file again. A server-dependent tool fails immediately. A local tool keeps working, because the engine and the page are already in the browser.

PocketPDF adds a service worker so that a page you have visited can be reopened offline. The worker caches the site—s own HTML, CSS, JavaScript, fonts and engines; it does not cache your documents. The offline page explains the edge cases: a tool you have never opened, an OCR language you have never used, or a browser that clears site data aggressively.

Why local tools have limits

The architecture that makes the privacy claim true is the same architecture that produces the rough edges:

  • Memory. A tab has a budget. Large PDFs, high-resolution images and video frames all compete for it. The browser may kill the tab rather than let it use the whole machine.
  • CPU. One laptop doing video encoding is slower than a rack of servers. For short clips the difference is small; for a feature film it is not.
  • 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.
  • No office engine. A faithful Word/Excel/PowerPoint — PDF conversion needs a full office renderer. Running one properly in a tab is not realistic, which is why that tool is absent rather than fake.

Extensions, devices and the things a website cannot control

A browser extension with permission to read and change pages can read what the page can read, including a file you have opened. That is true of any website and any local app. Use extensions you trust, or use a private window with extensions disabled for sensitive documents.

A compromised device, a keylogger, or someone with physical access can see the file before or after the browser does. Local processing protects against a server-side copy; it does not protect against a hostile endpoint. The security page lists these limits without pretending they do not exist.

The short version

A local file tool is a page that reads bytes through the File API, transforms them with JavaScript or WebAssembly, and hands back a Blob. The file never enters a network request. You can verify it with the Network tab and with an offline test. If a site cannot pass either test, —browser-based— is describing the interface, not the processing.