How to prove your file never leaves your device

Step 1 — Open DevTools

DevTools is the inspector built into every desktop browser. It only records while it's open, so do this before you touch a file.

Chrome, Edge, Brave and other Chromium browsers

Press F12. Or Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac. Or right-click anywhere on the page and choose Inspect.

Firefox

Ctrl+Shift+I on Windows and Linux, Cmd+Option+I on a Mac. F12 works as well.

Safari

Safari hides this behind a one-time setting. Go to Safari → Settings → Advanced and tick Show features for web developers. On older versions of macOS it's Safari → Preferences → Advanced → Show Develop menu in menu bar. After that, Cmd+Option+I opens the Web Inspector, or use Develop → Show Web Inspector.

Step 2 — Open the Network tab and filter it

The Network tab is a live list of everything the page sends and receives. Filter it down to the two things a page uses to send data, then clear it.

Chrome, Edge and other Chromium browsers

1. Click the Network tab.
2. In the filter row, click Fetch/XHR.
3. Tick Preserve log so the list isn't wiped if the page navigates.
4. Leave Disable cache unticked. Switching it on makes the browser re-download things it already has, which adds noise.
5. Click the Clear button — the circle with a line through it, top-left of the panel. The summary at the bottom should now read 0 requests.

Firefox

1. Click the Network tab.
2. In the toolbar above the request list, click XHR. Firefox files fetch() requests under XHR, so this catches both.
3. If you plan to reload, open the settings gear and tick Enable persistent logs.
4. Click the trash icon to clear the list.

Safari

1. Click the Network tab in the Web Inspector.
2. Above the request table is a segmented control for resource type. Choose XHR. Newer versions offer XHR and Fetch separately — if yours does, select both.
3. Tick Preserve log if you intend to reload.
4. Click the trash icon to clear the table. The counts below the table return to zero.

Where the summary sits: Chrome shows a status bar along the bottom of the panel reading something like 0 requests | 0 B transferred. Firefox and Safari show a request count and a total in the same place. That line is what you'll be reading.

Step 3 — Drop in a file and convert

1. Pick a file. Any file the tool accepts. A large one makes the test easier to read: if a copy of a 200 MB video went anywhere, the request would be unmissable. The video compressor is the loudest version of this test; HEIC to JPG is the quickest.
2. Add it. Drag it onto the page, or use the file picker.
3. Convert. Press the button and watch the panel while it works. On a photo this is a second or two; on a long video, longer.
4. Don't reload and don't navigate until you've read the count in step 4.

Step 4 — Read the number: 0 B of file data

When the result appears, look at the panel:

• One row appears, and it is the one named at the top of this page: /api/counter, a few hundred bytes, sent by this site's own public counter. It carries a tool name and a file count.
• No row carries your file. That is the number that matters, and it is the one that stays at zero.
• The timeline column at the right stays blank for the whole period — nothing the size of your file moves across it.

If a row did appear, click it. Three columns tell you what it was: Domain says where it went, Transferred says how many bytes, and Initiator (Chrome) or Cause (Firefox, enable it from the column menu) says what triggered it. An upload of your file would be a request to a server carrying roughly your file's size. Nothing that size is on screen, because nothing that size was sent.

The left-hand figures are illustrative of what an upload-based converter looks like in the same panel, not a measurement of any one named service. That is the point of this page: run the five steps against any converter you like and read your own counter, rather than taking a number — including this one — on trust.

Step 5 — The strongest version: do it with the network off

Everything above is a measurement. This step is a switch, and it's harder to argue with.

1. Turn on Airplane Mode, switch off Wi-Fi, or pull the Ethernet cable. Don't close the tab and don't reload yet.
2. Drop the same file in and convert it again.
3. It finishes. The result downloads to your usual downloads folder.
4. The panel still shows 0 new requests.

If the conversion needed a server, cutting the connection would stop it. It didn't, because there was never a round trip to cut. That's your machine's own switch, not a setting we control.

Two ways to push it further:

• Reload while still offline. After a first visit your browser keeps the page and the engine in its own storage, so a reload with no connection still works. If your browser has evicted it, open a tool once while online and repeat.
• Skip the airplane mode. Chrome and Firefox have an offline switch of their own — the throttling dropdown in the Network toolbar, set to Offline. It's quicker, but a real switch is better evidence, so use the real one if you can.

What you should see

Write these down before you run it, then compare:

Why this is conclusive

DevTools is not part of the page. It's part of the browser, and it sits underneath the page: every request the page makes passes through the browser's own network layer and is written into that list. A page cannot reach down and delete a row from a log it never had access to.

There is also nowhere to hide the traffic. Sending a file anywhere means making a request that has a destination and a size, and both are printed on screen. Size is the part that gives an upload away — a 200 MB file going out is a 200 MB request, and there's no way to make it smaller.

The filter you set in step 2 catches the two common methods, but it isn't the only net. WebSocket frames, background beacons, image requests and form posts all show up in the same panel. If you want the stricter version, clear the panel, set the filter back to All, and convert again: on a warm page the only new row is the counter named at the top of this page — nothing else, and nothing carrying your file.

And if you want a witness outside the browser entirely, a host firewall or network monitor logs the same connections from the machine's side. You don't need it. It's there if you want it.

What will not show zero

This is the part most sites skip. Here it is plainly.

• The first visit downloads the engine. The code that does the converting lives in a file your browser fetches once and then keeps. On a video tool that file is the largest thing on the page, tens of megabytes; on the image and PDF tools it's smaller. It's a download to you, not an upload of your file, and the second run doesn't fetch it again.
• The page itself loads. The HTML, the stylesheet, the icons, the fonts. A normal page load is a few hundred kilobytes. That happens before you choose a file and has nothing to do with the conversion.
• The type and icons are served from this site. The fonts and the icon set download from the same origin as the page — no third-party font service is involved. If you'd rather not have them, block them; the page still renders and the conversion still works, which you can confirm with step 5.
• Reloading with the cache disabled re-requests the engine. Turn that setting off and the noise goes away.

So the accurate claim is narrow, and it's the only one we make: the conversion produces no request that carries your file. The page does not load with 0 requests, and the conversion does send the one counter request named at the top of this page. Nobody's page loads silently.

If something doesn't look right

• "I see requests the moment the page loads." Expected. That's the page, its fonts and, on a first visit, the engine. Clear the panel after the page has settled and start the test from a clean zero.
• "I think my browser filtered the requests out." A filter hides rows, it doesn't delete them. Set the filter back to All and count again — every request of every type is in that list. Separately, the log does clear itself on navigation: tick Preserve log (Chrome, Safari) or Enable persistent logs (Firefox) and don't reload mid-test.
• "There are requests I don't recognise." Check the Domain column. Extensions, ad blockers, password managers and font services all make their own requests and they appear in the same list. To rule them out, run the test in a private window with extensions switched off.
• "I'm on a work laptop." Managed machines talk to internal endpoints you didn't ask for: proxy checks, update services, single sign-on. Sort by Domain and look for anything that isn't the tool you're using — or skip straight to step 5, where those stop too.
• "The count isn't zero but offline worked." You probably caught the tail of the first-visit download. Run the conversion twice and read the second one.
• "Nothing happened when I added my file." Check the file type against the tool's page. Drag-and-drop onto the wrong spot can also be read as a navigation — if the page reloaded, clear and start again.

Questions

Could Filezaar be hiding the request from DevTools?

No. DevTools belongs to the browser, not to the page, and it sits below the page in the stack. A page cannot remove its own network activity from the browser's own log — if it could, the same trick would work against every developer, security researcher and journalist who has ever opened that panel. The only way to send data is to make a request the browser handles, and every request the browser handles is listed.

Does this work on a phone?

The panel doesn't, not directly — phone browsers have no DevTools. Two options: use a Mac to inspect iPhone Safari over USB (iPhone: Settings → Safari → Advanced → Web Inspector, then the Mac's Develop menu), or use desktop Chrome's chrome://inspect with an Android phone attached. Simpler, and stronger: put the phone into airplane mode and convert something. If it finishes with no connection, the file didn't go anywhere. That's step 5 without the panel.

What about extensions?

Extensions run with their own permissions and make their own requests, and those requests appear in the same panel. They can add rows; they cannot remove the ones a page makes. If your list looks busy, run the test in a private window with extensions disabled.

Does downloading the finished file count as network activity?

No. The result is produced on your device and handed to your browser's normal download mechanism. It doesn't appear as a request, and it works with the connection switched off — which is what step 5 shows.

I'm behind a VPN or a corporate proxy. Does that change the result?

It doesn't change the conversion, but it adds rows you didn't cause: proxy checks, DNS lookups, telemetry from the VPN client itself. Sort by domain and ignore anything that isn't the site you're testing. The offline step cuts through all of it.

What exactly does this prove — and what doesn't it?

It proves one thing: while a file is being converted, it isn't transmitted. That's measured, not promised, and the offline step is what makes it hard to argue with. It doesn't measure anything else about the site, and we're not claiming it does. Read the privacy policy for what is and isn't kept, or see how the tools work for the mechanics.

Check something else while you're here

The useful thing about this test is that it isn't specific to us. Run it on the next converter you're asked to trust. Open the panel, add a file, watch the counter. If a site is doing the work on your machine, you'll see nothing happen. If it isn't, you'll see your file leave.

Browse all tools — every one of them runs the same way.