How to check whether a website uploads your file.

Every online converter says something reassuring about privacy. Some of it is true. You cannot tell which from the wording, because the wording is written by the people who want you to upload the file. What you can do is watch what the page actually sends, using a tool that ships with every browser. This guide shows you how.

It works on any website. imissfiles is used as the example because it is the one we can show you real numbers for, but the method is the point, and the method does not care whose site it is.

What "upload" actually means

When you drop a file onto a web page, one of two things happens next.

Either the page sends the file to a server, the server does the work, and the page downloads the result — or the page does the work itself, inside your browser, and the file never leaves your computer. The first is how almost every converter has worked for twenty years. The second has been possible for a while and is still unusual.

The difference is not visible on the page. Both show a progress bar. Both give you a download. The only way to tell them apart is to look at the network traffic, which is exactly what your browser's developer tools are for.

The method

1. Open the converter page you want to check. Do not add a file yet.
2. Open developer tools. Press F12, or Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac. Every major browser has this.
3. Click the Network tab. It shows every request the page makes from now on. If it is already full, click the clear button (a circle with a line through it) so you start from nothing.
4. Now add your file and run the conversion.
5. Read the list. Each row is one request. You are looking at two columns: Method and Size.

How to read what you see

An upload is a request that sends a lot of data. On the Network tab it looks like this:

• The method is POST or PUT, not GET.
• The request goes to something like /upload, /api/convert, /process, or a storage host such as s3.amazonaws.com or a storage.googleapis.com address.
• The size roughly matches your file. A 3 MB photograph produces a request of about 3 MB. If the browser shows the request body, it will be your file, or an encoded version of it.

Local processing looks like the opposite. The requests after you add the file are all GET, they fetch code and libraries rather than sending anything, and nothing outbound is anywhere near the size of your file. Often there is nothing at all.

What it looks like here

This is a real recording, not an illustration. We loaded HEIC to JPG, cleared the Network tab, added a 31 KB iPhone photograph, and converted it. This is every request the page made from that point:

That single row is the decoder arriving. It is 1.4 MB coming in, which is the opposite direction from an upload. The 31 KB photograph does not appear anywhere, because it never left the tab.

Try the same steps on any converter you currently use. You will have your answer in under a minute.

Things that can confuse the picture

Ads and analytics. Most free sites, this one included, load advertising and analytics scripts. Those show up as requests to Google domains. They are small, they happen whether or not you add a file, and they do not carry the file. Filter the list to the site's own domain, or just check whether any request is the size of your document.

Libraries loading late. A local tool often fetches its engine only when you first use it — which is what you saw above. That is a download of code, not an upload of your file. Direction and size tell them apart.

A page that uploads a "fingerprint". Some services send a hash of the file rather than the file itself, to check a cache or a blocklist. That is a small POST, a few dozen bytes. It is not your document, but it is information about your document, and you may or may not be comfortable with it. Now you know how to spot it.

Chunked uploads. Large files are sometimes sent in pieces. Instead of one 40 MB POST you see forty 1 MB POSTs. Same conclusion.

Why this matters more than a privacy policy

A privacy policy tells you what a company intends. Network traffic tells you what the page does. Intentions change, policies get rewritten, and retention periods are promises you cannot inspect. A request that never leaves your machine is not a promise. It is an absence, and absences are easy to verify.

This is also why we describe imissfiles the way we do. It is not that we promise not to look at your files. It is that there is no endpoint in the code that could receive one, which means the claim can be checked by anyone with a browser rather than trusted on faith.

When uploading is fine

Most of the time. A restaurant menu, a flyer, a public report — nothing is at stake and the convenience is real. Server converters also handle files that would exhaust a browser tab, and they work the same on a weak device. This method is not an argument that uploading is always wrong.

It is for the other case: a bank statement, a signed lease, a passport photograph, a medical letter, anything with a signature or an account number on it. For those, it is worth thirty seconds to see where the file goes before you send it.

Common questions

Tools on this page

• HEIC to JPG — iPhone photos into JPEGs anything can open.
• Merge PDF — Combine PDFs in any order, in this tab.
• Compress PDF — Shrink a PDF for email without sending it anywhere.
• Image to Text (OCR) — Read the words out of a photo or screenshot.