How to check that a website is not uploading your photos

You can check whether a website is uploading your photos yourself, in about two minutes, with tools already built into your browser. Every request a web page makes passes through the browser, and the browser will show you all of them: where each one went, what it carried and how big it was. An upload is not subtle in that list. It is a request from your computer to a server with your whole file inside it.

This guide shows how to open that list in Chrome, Edge, Firefox and Safari, what an upload looks like when you find one, a second test that needs no technical reading at all (going offline), and exactly what you will see if you run both tests on getPNG. It ends with the limits, because a test that is oversold is worse than none.

What an upload looks like

Before opening anything, it helps to know what you are looking for. When a site sends your photo to its server, the browser makes an HTTP request with these marks:

• The method is POST or PUT. Requests that only fetch something use GET. A request that carries data to a server almost always uses POST or PUT.
• The request body is about the size of your file. A 4 MB photo makes a request of roughly 4 MB. If the site wraps the file in a form, add a few hundred bytes. If it encodes the photo as text (base64), the request is about a third larger than the file.
• The content type gives it away. Look in the request headers for Content-Type: multipart/form-data (the format of a classic file upload form), image/jpeg, image/png or application/octet-stream.
• It takes time. Upload speeds are slower than download speeds on most home connections, so a large upload is often the slowest request in the list.
• It may come in pieces. Some services split big files into chunks of a few megabytes, each its own POST or PUT. The sizes add up to the file.

Direction is the thing people get wrong. A big download is normal: pages fetch scripts, fonts and, for AI tools, model files that can be tens of megabytes. Those are GET requests with a large response. An upload is a request with a large body. Keep that distinction and the log becomes easy to read.

Open the network log in your browser

The steps below were checked against each browser’s own documentation in September 2026. Open the tools before you use the site, because the log only records requests made while it is open.

Chrome

1. Open the site, then press F12 or Ctrl+Shift+I (Cmd+Option+I on a Mac). From the menu it is the three dots at the top right, then More tools, then Developer tools.
2. Select the Network tab.
3. Tick Preserve log, so the list survives if the page reloads.
4. To see the method of each request, right-click the column headers and choose Method.
5. Click any request to see its details. Headers shows the method and the request headers; Payload shows what was sent.

Microsoft Edge

Edge is built on the same engine as Chrome, and its developer tools are almost identical.

1. Press F12 or Ctrl+Shift+I, or right-click the page and choose Inspect. From the menu it is Settings and more (the three dots), then More tools, then Developer tools.
2. Select the Network tool. If you cannot see it, it sits behind the More tools button in the developer tools’ own toolbar.
3. Tick Preserve log, add the Method column by right-clicking the headers, and click a request to see Headers and Payload.

Firefox

1. Press Ctrl+Shift+E (Cmd+Option+E on a Mac) to open the Network Monitor directly. From the menu it is the three lines at the top right, then More tools, then Web Developer Tools, then the Network tab.
2. Firefox shows the Method column by default, along with the domain, the file name, the type and the transferred size.
3. Click a request. Headers shows the request headers, and the Request tab shows the body that was sent.
4. If the page reloads during your test, turn on persistent logs from the Network Monitor’s settings menu (the gear icon), so the list is kept.

Safari on a Mac

1. Safari hides its developer tools until you ask. Choose Safari, then Settings, click Advanced, and tick Show features for web developers.
2. A Develop menu appears in the menu bar. Choose Develop, then Show Web Inspector, or press Option+Cmd+I.
3. Select the Network tab. Every resource the page loads while Web Inspector is open appears as a row; click a row’s name to see its request and response details.

On an iPhone or iPad there is no network log on the device itself. Web Inspector can be turned on in the device’s Safari settings and used from a Mac over a cable, but for most people the offline test below is the practical check on a phone.

Run the network test, step by step

1. Open the site and the developer tools, and select the Network tab.
2. Clear the list (the circle with a line through it in Chrome and Edge, the bin icon in Firefox), so that only what happens next is recorded.
3. Pick a photo that is several megabytes. A big file makes an upload impossible to miss, because nothing else a normal page sends is that large.
4. Drop the photo on the site and let it finish the job: a converted file, a cutout, whatever the tool does.
5. Read down the list. Ignore rows with the method GET. For each POST or PUT, look at the size, and click it to open Payload (Chrome, Edge) or Request (Firefox).
6. In the request headers, compare Content-Length with your file’s size in bytes. The file’s size is in its properties (right-click the file on Windows, Get Info on a Mac).

The offline test

The network log shows what was sent. The offline test answers the question more bluntly: can the site do the job at all without a connection? A site that processes photos on a server cannot.

1. Use the tool once while online, so that everything it needs has loaded. AI tools in particular fetch their model on first use.
2. Do not reload the page. Keep the tab open.
3. Go offline. In Chrome and Edge, open the Network tab, find the throttling menu (it reads No throttling until you change it) and choose Offline. In Firefox, the Network Monitor’s Throttling menu also has Offline. The stronger version, which works in every browser including Safari and on phones, is to switch off Wi-Fi and unplug any cable, or turn on airplane mode.
4. Process a new photo. Use a different one from before.

If the result appears, the photo was processed on your device. If you see an error, or a progress indicator that never ends, the site needs its server for the work.

The switch in the developer tools only affects that tab, and it may not cover every kind of connection a page can make. Turning the network off at the system level covers everything, which is why it is the better test when the answer matters.

What you will see on getPNG

getPNG says a photo never leaves your device, and the privacy page says to check rather than trust it. Here is what the network log shows on getpng.app, verified on 16 September 2026, so you can compare line by line.

When the page loads:

• The page itself, getpng.app/, then its stylesheet and scripts from getpng.app/_astro/, and its fonts (.woff2 files) from the same place.
• Small thumbnails of the sample photos from getpng.app/samples/thumbs/.
• Google Tag Manager, gtm.js and gtag/js from www.googletagmanager.com, then requests to /g/collect on a google-analytics.com address. This is Google Analytics counting the visit, as on most websites. A content blocker stops it without affecting the tool.

When you process your first picture:

• The worker script from getpng.app/_astro/, and a blob: address, which is the browser loading code it already has, not a network request to anyone.
• The runtime that runs the model, two files under getpng.app/ort/.
• The model files under getpng.app/models/: a small configuration file and the weights. The weights are large: about 44 MB for the model that runs on the processor, 115 MB on a computer whose graphics card runs the larger model, and a 4.6 MB quick model that gives a first result while the main one gets ready. These are GET requests with large responses: downloads to you, not uploads. The browser keeps them, so on later visits they come from its cache and may not appear in the log at all.
• If you try a sample instead of your own photo, the sample picture itself is fetched from getpng.app/samples/.

When the background has been removed:

• One POST to getpng.app/api/count. Its body is {}, two characters, and the answer is 204 No Content. It adds one to a number for the day and carries no identifier, no file name, no dimensions and nothing about the picture. Chrome may list it with the type ping, because it is sent as a beacon.
• More /g/collect requests to Google Analytics, which record that a cutout was made, which runtime ran the model and, when you download, which file format and which kind of background you chose. No file names, dimensions, colours or anything derived from the image.

What you will not see: any request whose body comes anywhere near the size of your photo. Download the PNG and the only new row is the small analytics request for the download: the file itself is written inside the browser and saved straight to your disk.

The security policy that enforces it

You can also read the rule that makes this more than a promise. Click the first row, the page itself, open Headers, and find content-security-policy under the response headers. Its connect-src part lists every address the page is allowed to send data to with scripts: 'self' (getpng.app), blob: and data: (local to the browser), and Google Analytics’ own addresses. The browser refuses any other connection, whether it comes from getPNG’s code, a library it uses, or a tag added to Tag Manager. If the site ever tried to post a picture to another host, the browser would block it and print an error in the Console tab.

Limits of the test

These checks are strong evidence, but they are not a certificate. Be clear about what they cannot show:

• They cover one session. A website can change its code at any moment. The result is true for the version you tested, today.
• A site could upload later. A page that works offline might still send the photo once you reconnect. Leave the network log open for a minute after you go back online, and process a photo with it open.
• Some connections do not appear in the Network tab. WebSocket traffic appears (filter by WS and open the Messages view), but peer-to-peer connections made with WebRTC do not show as ordinary requests, and developer-tools offline mode may not stop them. Switching the whole device offline does.
• Small can still be personal. A thumbnail of a face can be a few kilobytes. A missing large request rules out the full file, not every derivative of it, so glance at the bodies of small POST requests too.
• Browser extensions make their own requests. Some appear in the log and some do not, and an extension with access to every page can read what is on it. Test in a private window with extensions off if in doubt.
• Apps are another matter. A phone or desktop app does not go through the browser, so none of this applies. Airplane mode still does.
• Analytics is a separate question. A site that never uploads photos may still record your visit. The log shows those requests too; the privacy policy says what they contain.

For what the popular upload-based tools say they do with your files, and when that is perfectly fine, see is it safe to upload photos online?. If you are about to cut out a picture, how to make a transparent PNG compares the ways to do it, and the app-by-app guide notes which built-in removers work on your device and which send the photo to a server.

The steps, in short

1. Open the network log. Press F12 (Windows) or Cmd+Option+I (Mac) in Chrome, Edge or Firefox, or enable the Develop menu in Safari, and select the Network tab.
2. Clear it and keep it. Clear the list and tick Preserve log (Chrome, Edge) so requests are not lost if the page reloads.
3. Use a large photo. Drop a photo of a few megabytes on the site, so that an upload would stand out from everything else in the list.
4. Look for a large outgoing request. Check the method of every request made while the photo was processed. A POST or PUT with a request body close to the file size is an upload.
5. Inspect the suspicious request. Click it and read the Payload tab (Chrome, Edge) or the Request tab (Firefox) to see what was sent.
6. Repeat the job offline. Without reloading, set the throttling menu to Offline or switch off Wi-Fi, then process another photo. If it works, the processing happens on your device.

Questions

How can I tell if a website uploads my files?

Open the Network tab in your browser's developer tools before you use the site. An upload appears as a POST or PUT request with a request body about the size of your file. Then disconnect from the internet and try again: a site that uploads cannot finish the job offline.

What does an upload look like in the Network tab?

Usually one request with the method POST or PUT, a Content-Type of multipart/form-data or image/jpeg, and a Content-Length header near your file's size. It often takes noticeably long to finish on a slow connection. Large uploads are sometimes split into several requests of a few megabytes each.

Is the offline test enough on its own?

It proves the work is done on your device, but not that the photo is never sent later. A site could process locally and upload when you reconnect. Leave the network log open after you go back online to rule that out.

Does a large download in the network log mean my photo was uploaded?

No. Direction matters. A GET request with a large response is something coming to you, such as an AI model or a script. An upload is a request that carries a large body from your browser to a server.

Can I check a phone app the same way?

Not with browser tools. Apps make their own connections, which only a network proxy or the phone's privacy report can show. On iPhone, a website in Safari can be inspected from a Mac with Web Inspector, and airplane mode works as an offline test for both apps and websites.

What will I see on getpng.app?

The page, its scripts and fonts, and on the first picture the AI model files, all from getpng.app; Google Tag Manager and Google Analytics requests; and after each cutout one POST to /api/count with a body of just two characters. No request carries your image.