Local vs Server Processing: How to Tell If an Online Tool Uploads Your Files

What local processing actually means

Local processing means the file is opened by your browser and never sent anywhere. The sequence is roughly the same every time: you pick a file, the browser hands the page a File object (a reference plus metadata, not a copy of the bytes), the page reads the bytes only when needed, and the result becomes a Blob that turns into a download link.

• It does mean the content stays in the tab: no server copy, no retention policy to trust, no third party in the loop.
• It does not mean the page is offline: the page, its libraries and its fonts were downloaded first, and page code can call the network for other reasons.
• It is not storage: data sits in the tab's memory, so closing the tab discards it and a crash loses work in progress.

The browser capabilities that make it possible

This is not exotic: a handful of long-standing platform features covers almost every local tool.

What uploading actually exposes

Uploading is not automatically unsafe; it turns a technical question into a trust question. Whether the operator's handling of your file is acceptable is mostly taken on their word.

• Transport: the file crosses the network, so its safety rests on correct TLS and on nothing logging the body.
• Retention: how long the file is kept, whether it is deleted afterwards, whether backups survive. A policy rather than a guarantee.
• Third parties: object storage, CDNs and scanning services each add a copy you did not choose.
• Access: staff, support tooling or an attacker with server access can read what is stored, and a file that was never uploaded cannot leak.
• Compliance: identity documents, payslips and medical files carry personal data, so uploading can make the operator a processor and place copies in another jurisdiction.

Check 1: watch the Network panel while you use the tool

This works on any tool, including this site's, and takes about a minute.

1. Open the tool plus developer tools (F12, or Ctrl+Shift+I; Command+Option+I on macOS), then the Network tab.
2. Clear the list, tick Preserve log, and set the filter to All rather than only Fetch/XHR, since a form post shows up as a document request.
3. Pick your file, run the main action, then stop touching the page.
4. Sort by the Size column and compare the largest request with your file: if a 12 MB PDF produces no request near 12 MB, it was not uploaded.
5. Open anything suspicious and read the Method, Request URL, Content-Length and Payload. A POST with multipart data naming your file is the giveaway.
6. Check the quiet channels: WebSocket frames appear under the WS filter, and pages sometimes send data on unload with sendBeacon or keepalive.

For a fully local tool the list holds only the page, its scripts, styles and fonts - none of it your file, and the sizes show that.

Check 2: disconnect and repeat the task

The second check is cruder and harder to argue with: remove the network and repeat the task.

1. Load the tool page fully while you still have a connection.
2. Disconnect: turn off Wi-Fi, enable airplane mode, or choose Offline in the Network tab.
3. Pick a new file and run the whole operation, then check that the downloaded result is correct.
4. If it completes with valid output, the work happened on your machine: an upload could not have succeeded.
5. Reload while still offline. If the page loads, a service worker cached it; if not, that only means the app is not offline-installable.

Two caveats. Going offline proves the step needs no server at that moment, but a page could queue data and send it after you reconnect, so check the Network tab again. And many tools are partly local: an IBAN checker can do the checksum in the browser while still sending a country code and bank code for a name lookup.

When local processing is the wrong choice

Local processing has hard limits, and the main one is memory.

• Decoded images cost roughly four bytes per pixel, so an 8000 by 8000 pixel scan is about 256 MB before copies, and drawing it can hold two or three such buffers.
• PDF libraries usually load a whole file into memory and keep several representations, so a few hundred megabytes is a realistic failure.
• Mobile browsers are stricter: Safari on iOS caps tab memory and reclaims it aggressively, and a page that reloads mid-task was usually killed for using too much.
• Some work does not fit in a tab at all: video transcoding, heavy OCR, large machine-learning models. Scale and persistence need a server too: hundreds of files, scheduled or resumable jobs, a permanent archive, a shared team history.
• A local tool cannot scan a file for malware, so with untrusted files a service that scans uploads may be the safer trade.

What this looks like in practice

The tools used as examples here are built this way. The image resizer reads your file with the File API, draws it to a canvas and re-encodes it there; the PDF merge and image-to-PDF tools assemble pages with a JavaScript PDF library running in the page. None of them makes a network request while you work, and both PDF tools keep working after you disconnect, as long as the page is loaded.

One detail, so the numbers do not mislead you: the resizer estimates output size from the base64 data it produces, so treat it as approximate.

The same site also shows what partly local looks like. The IBAN checker performs the whole MOD-97 calculation in the browser, but it looks up the bank name and BIC behind a bank code, and that request carries only the country code and bank code, not the full IBAN. Seconds in the Network tab will confirm it. The Minecraft player-colour lookup is a different case: the colour maths runs locally, but the player name you type is sent to the public PlayerDB API to resolve it to a UUID.

Frequently asked questions

Tools used in this guide

More guides