How to Check If a Website Uploads Your Files: A DevTools Tutorial

“Online converter” describes two completely different architectures. Some tools are server applications with a web page bolted on the front: your file travels to their machine, gets processed there, and a result comes back. Others run entirely in your browser using JavaScript or WebAssembly, and your file never leaves your device. The page looks identical either way.

The good news: you don’t have to trust anyone’s privacy policy. Your browser logs every byte that leaves it, and the log is open to you. This guide shows you how to check if a website uploads your files using nothing but DevTools, in about two minutes.

Why “we delete your files” is not “we don’t upload your files”

Most converters are honest about being server-side, just quietly. Ezgif, one of the most popular GIF tools on the web, states plainly in its privacy policy that uploaded files are stored on their servers for up to 1 hour after last use, then deleted. That’s a reasonable policy, and there’s nothing shady about it.

But “deleted after an hour” still means your file crossed the internet, sat on someone else’s disk, and existed in their logs and backups for some window of time. For a meme clip, who cares. For a screen recording with your email inbox visible, a clip of your kids, or anything from work, the difference matters. So does the failure mode: you’re trusting their retention script, their server security, and every CDN hop in between.

A truly client-side tool has nothing to delete because it never received anything. That’s a verifiable claim, not a promise. Here’s how to verify it.

Step 1: Open DevTools

Browser	Windows / Linux	macOS
Chrome	`F12` or `Ctrl+Shift+I`	`Cmd+Option+I`
Edge	`F12` or `Ctrl+Shift+I`	`Cmd+Option+I`
Firefox	`F12` or `Ctrl+Shift+E` (opens Network directly)	`Cmd+Option+E`

Right-click → “Inspect” works everywhere too. Firefox’s Ctrl+Shift+E is handy because it jumps straight to the Network Monitor, which is where we’re headed anyway.

Step 2: Set up the Network tab

Click the Network tab. Before testing, do three things:

Check “Preserve log” (Chrome/Edge) or the gear → “Persist Logs” (Firefox). Some sites redirect or reload after a conversion, which wipes the request list. You want history to survive that.
Clear the list (the 🚫 icon, or Ctrl+L in Firefox) so you start from zero.
Optionally check “Disable cache” so you see real traffic, not cached responses.

Leave DevTools open from this point on. The Network tab only records while it’s open.

Step 3: Filter for uploads

A page makes dozens of requests for fonts, scripts, and analytics. You only care about requests that carry data out. Two filters cut the noise:

Filter by method. Type method:POST into the filter box in Chrome or Edge (documented in the Network features reference). File uploads ride on POST or PUT requests; you can also type -method:GET to show everything except plain fetches.
Filter by type. Click the Fetch/XHR filter button to show only programmatic requests, which is how a script would phone home.

When a request looks suspicious, click it and check two places:

Headers → Request Headers → Content-Length. This is the size of what was sent. A telemetry ping is a few hundred bytes. Your 40 MB video shows up as a Content-Length around 40,000,000.
The Payload (Chrome) or Request (Firefox) tab. A file upload typically appears as multipart/form-data with a filename in it, or as raw binary.

Don’t be alarmed by every POST. Analytics beacons, error reporters, and consent banners all POST small payloads. The tell is size: nobody accidentally uploads 40 MB of telemetry.

Step 4: Convert a file and watch

Now do a real conversion with a file you don’t mind testing with. Drop a video into the tool, start the conversion, and watch the request list while it runs.

What you’ll see, by architecture:

Signal	Server-side converter	Client-side converter
Request during conversion	POST/PUT with `Content-Length` ≈ your file size	Nothing, or tiny analytics pings
Progress bar meaning	Upload progress (network-bound)	Encode progress (CPU/GPU-bound)
Result delivery	Download from their server (a GET for the output file)	A `blob:` URL generated locally, no network request
Works offline?	No	Yes

That third row is a nice bonus check: if the finished GIF downloads from a blob: or data: URL instead of an https:// URL on their server, the file was assembled in your browser’s memory.

The airplane-mode test

The Network tab requires you to read; this test requires nothing.

Load the converter page normally.
Cut the connection. The clean way in Chrome and Edge is the Network tab’s throttling dropdown: switch it from “Online” to “Offline” (reference). The blunt way that works in any browser: turn off Wi-Fi or flip on actual airplane mode.
Convert a file.

A server-side tool fails instantly, because there’s no server to reach. A client-side tool doesn’t notice. All the code it needs already arrived when the page loaded, and the work happens on your CPU.

One caveat: do this after the page has fully loaded, since even client-side tools need the network once to fetch their own JavaScript or WASM. And if a site uses a service worker, a cached page shell might load offline while the actual conversion still fails, so judge by whether the conversion completes, not whether the page renders.

Bonus: read the CSP `connect-src` header

This one’s for the thorough. A site can ship a Content-Security-Policy response header whose connect-src directive tells the browser which origins scripts are allowed to contact. Per MDN, it governs fetch(), XMLHttpRequest, WebSockets, EventSource, and even navigator.sendBeacon(), which covers essentially every way JavaScript can exfiltrate data.

To check it: Network tab → click the main document request (the first one, type document) → Headers → Response Headers → look for content-security-policy. If you see something like connect-src 'self', the browser itself will block any script on that page from sending data to a third-party server, even if the site’s code tried. It’s a self-imposed handcuff, enforced by your browser rather than by the site’s goodwill.

A strict connect-src is rare among converters and a strong signal when present. Its absence proves nothing; plenty of honest sites just never set one.

What these tests can and can’t tell you

Be honest about the limits. The Network tab shows you what happened during your session: it can’t promise the site won’t ship different code next week, so a privacy-critical workflow deserves a re-check now and then, and chunked or resumable uploads show up as many medium-sized POSTs rather than one big one (the total still adds up to your file size, so sort by size). What the tests can’t be fooled by is obfuscation: there is no way to send your file to a server without the Network tab recording it. The browser sits below the page’s code.

This is exactly why GIF Den publishes a walkthrough for verifying its own no-upload claims: the video to GIF converter is built so that the Network tab stays empty during a conversion and the airplane-mode test passes, and the same holds for the GIF compressor and GIF resizer. You shouldn’t take that paragraph’s word for it either. That’s the whole point: run the tests.

The 2-minute checklist

Open DevTools (F12) → Network tab → enable “Preserve log” → clear the list
Filter with method:POST or the Fetch/XHR button
Convert a throwaway file and watch for any request with Content-Length near your file’s size
Check whether the result downloads from a blob: URL (local) or an https:// URL (their server)
Re-test with the throttling dropdown set to “Offline”: a client-side tool still works
Optional: check the document’s Content-Security-Policy header for a strict connect-src

If a converter passes the offline test and the Network tab stays quiet under load, your files stayed on your machine, regardless of what the marketing copy says. If it fails, that’s not necessarily sinister, but now you know what you’re agreeing to before you drop in anything sensitive.