← All guides

Does an online video compressor upload your file?

Usually yes. Most sites that compress a video take the file onto their own servers, do the work there, and send the result back. A smaller number do the work inside your browser, in which case the file never leaves your device. The two look identical from the outside: same drop zone, same progress bar, same download button at the end.

You do not have to take anyone’s word for which one you are using. Chrome can tell you in about a minute, and the check works on any site. That is section 3, and it is the part worth keeping.

1. The two ways a compressor can work

Server side

Your browser sends the whole file to a server. The server runs the encoder, writes the smaller file, and hands you a link to download it. The original sits on someone else’s disk for as long as their retention policy says.

Most tools work this way, and the reason is practical rather than sinister. The server is one known machine the developer controls, so the encoder runs at native speed with every codec available, and the result is the same whether you arrived on a new laptop or a five year old phone. It is the straightforward way to build the thing.

In the browser

The page downloads an encoder, usually a build of ffmpeg compiled to WebAssembly, and runs it on your own machine. Your video is read from disk into the tab’s memory, encoded there, and offered back to you as a download. Nothing about the video is sent anywhere.

The tradeoffs are real. The encoder is a large one time download, speed depends on your machine, very large files can run into browser memory limits, and codec support is narrower than a server build. That is why this approach is the minority.

2. What happens to a file you upload

The transfer itself is almost always fine. Reputable converters send files over TLS, which is what the padlock in the address bar means: nobody on the coffee shop wifi or at your ISP can read the video on its way up. Convertio, for instance, states that traffic between your browser and its conversion hosts uses TLS with HSTS enabled.

TLS protects the file in transit and stops there. It is decrypted the moment it arrives, because the server has to read the video to encode it. From that point the protection is not cryptography, it is the operator’s policy and practice: who on the team can reach the storage bucket, what the logs keep, which subprocessors are in the path, how long the file stays.

The stated retention windows are short and they vary. CloudConvert says files are deleted when you press the delete button and automatically at the latest after 24 hours. Convertio says input and temporary files go immediately after conversion and output files after 24 hours. FreeConvert says uploaded files are permanently deleted after 8 hours. Those are reasonable policies from companies with a reputation to protect.

The honest point is about what kind of statement that is. From outside the company you cannot verify a deletion. You cannot see the disks, the backups, or the logs. Nothing here suggests any of these services fail to do what they say. It is simply that a retention policy is a promise you are trusting, while a file that never left your device is a fact you can check. The rest of this guide is about doing the checking.

3. How to check any site yourself

This is a Chrome walkthrough. Edge is identical, Firefox and Safari have the same panels under different names. Use a video you do not mind sending, since a server side tool will send it.

Set up

  1. Open the compressor site. Do not pick your file yet.
  2. Open DevTools with Command+Option+I on macOS or Control+Shift+I on Windows and Linux, then click the Network tab. Requests are only recorded while DevTools is open, so leave it open.
  3. Right click any column header in the request table and tick Method. That adds a column showing GET, POST, PUT and so on for every request, which is how you read direction.
  4. Click the clear button so the list starts empty.
  5. Now choose your video and start the compression.

Read the result

An upload is a request whose body carries the file. In practice that means a POST or PUT, or a run of them if the site uploads in chunks. Click the suspicious row, open the Headers tab, and look under Request Headers for Content-Length. If that number is in the same neighbourhood as your file’s size in bytes, your video went up. The Payload tab on the same row shows the form data that was sent.

If the compression runs to completion and no POST or PUT with a multi megabyte Content-Length ever appears, the work happened on your machine.

The Size column is not the upload

This is the one thing that trips people up. Chrome’s Size column shows the response headers plus the response body as delivered by the server, which is what came down. A browser based tool will often show a very large number there, because it just downloaded its encoder. That is a download, not an upload.

The filter box has a larger-than keyword, so larger-than:1M hides everything small. It filters on that same response size, which makes it a good way to find the big download and the wrong tool for finding the upload. Tell them apart on three signals:

The blunt version

If you would rather not read headers: compress one file normally so the page has everything it needs, then in the Network tab set the throttling dropdown to Offline and compress a second file without reloading. A server side tool cannot work with the network cut. A browser based tool finishes as usual.

Two caveats so this stays honest. A tool that runs locally may still send small requests for analytics or ads, so the test is about megabytes moving, not about the request count being zero. And a page can always change what it does in a later release, so the check tells you about the site as it is today, not forever.

4. When it matters and when it does not

Server side is not a scandal. For a meme clip, a game highlight, or anything you were about to post publicly anyway, uploading it to a converter for a few hours is not a meaningful risk. Convenience wins, and these services are genuinely useful.

It matters when the content is one you would not hand to a stranger:

For those, the question is not whether a company is trustworthy. It is whether you need to make the judgment at all. If the file never leaves the device, there is no policy to evaluate and no breach to be part of.

One disclosure, since we wrote this: our video compressor does the encoding in your browser, which is why our privacy page is short. Run the section 3 check on us the same way you would on anyone else.

Common questions

The site uses HTTPS. Isn’t my file safe?

HTTPS means nobody could read the file while it travelled. It says nothing about what happens after it arrives, because the server has to decrypt the video in order to encode it. The padlock is about the journey, not the destination.

Files are deleted after 24 hours. Isn’t that fine?

Usually, yes, and the major services publish windows in that range. The limitation is that you have no way to confirm it from outside. It is a commitment you are choosing to trust rather than something you can observe, which is a fine trade for a meme clip and a worse one for a medical recording.

My browser downloaded 30 MB. Did it upload my video?

No. A large download at the start is the signature of a tool that runs locally: it is fetching the encoder. Check the Method column, a download is a GET, and check Request Headers for a large Content-Length, which only an upload has.

Are browser based compressors worse at the job?

They are slower on old hardware, they struggle with very large files because a browser tab has a memory ceiling, and they support fewer exotic formats. Quality at a given target size is not the difference, since both are usually running the same ffmpeg code. Speed and reach are.