Does that image tool upload your photo? Check it yourself

“No upload” is a claim you can test

You need to shrink a photo of your driver's license for an apartment application, and the compression site promises that “your files never leave your device.” Maybe that's true. Maybe the line was copied from another site. Either way, it's one of the few online promises you can check yourself, with nothing to install.

A page talks to servers through network requests, and your browser logs them in the Network panel of its developer tools. If your 3 MB photo left your device, some row in that list carried about 3 MB out.

How to open the Network panel in Chrome, Edge, Firefox and Safari

Open the panel before you pick the image: it only logs what happens while it's open. On a phone these panels need a connected computer, so use the offline test below.

Chrome and Edge

1. On the tool's page, press F12 or Ctrl+Shift+I (Cmd+Option+I on a Mac). Right-click > Inspect works too.
2. Click the Network tab and check Preserve log so the list survives a page reload.
3. In the filter box, type method:POST. Repeat later with method:PUT.
4. Pick your image and run the tool as usual.
5. Click each row that appears. Under Headers, find Content-Type and Content-Length in the request headers; Payload shows the data sent.

Firefox

1. Press Ctrl+Shift+E (Cmd+Opt+E on a Mac) to open the Network Monitor.
2. In the toolbar's actions menu, turn on Persist Logs.
3. Filter with method:post, then run the tool.
4. Click a request: Headers lists the headers and Request shows what was sent.

Safari on a Mac

1. Choose Safari > Settings, click Advanced, and select “Show features for web developers.”
2. Choose Develop > Show Web Inspector (⌥⌘I) and open the Network tab.
3. Right-click the table header to add the Method column, and check Preserve Log.
4. Select a request: Headers shows the headers and Sizes breaks down the payload sizes.

What an upload looks like next to normal traffic

An upload usually has three tells. The method is POST, which sends data to the server, or PUT, which creates or replaces a resource with the content you send. The Content-Type is often multipart/form-data, the encoding used when a form includes files. And Content-Length, the size of the message body in bytes, lands close to the size of your photo.

Don't go by the Size column. In Chrome it adds up the headers and body of the response. A 3 MB upload can show a few hundred bytes there, because all the server sent back was “got it.” What left your device is in the request's Content-Length.

Not every POST is an upload. Usage analytics travel the same way, carrying a small amount of data. When in doubt, read the Payload: an analytics event is short text, names and numbers.

How do you run the airplane-mode test?

No network, no upload. If the tool still hands you a result with the device disconnected, the work happened on it.

1. Open the tool's page and let it finish loading.
2. If the tool downloads something on first use, such as an AI model, process any image once while you're still online.
3. Turn on airplane mode, then make sure Wi-Fi is off too: both iPhone and Android let Wi-Fi stay on in that mode.
4. Pick your image, process it and save the result.

The test proves where the image was processed, not that nothing gets sent later: a page can defer work until the connection comes back. On a computer, fake the outage with the Offline option in the throttling menu (Chrome, Edge and Firefox), then reconnect with the Network panel open.

What “processed in your browser” means

When you pick a file, the page gets access to it through the File API — only to files you handed over, through the file picker or drag and drop. In a tool like ours, the code decodes the image, draws its pixels onto a canvas, and asks the browser to write the result with canvas.toBlob(), passing the format and, for JPG or WebP, a quality between 0 and 1. The file you download comes out of memory, through a blob: URL.

Heavier jobs, like running an AI model, use WebAssembly: compiled code that runs in the browser at near-native speed, inside the same sandbox as the rest of the page.

The honest limit is your device's memory. Every decoded pixel takes 4 bytes, so a 48-megapixel photo at 8,000 × 6,000 occupies 192 MB once it's open, no matter how small the file is. The canvas has a ceiling too. According to MDN, the maximum usually exceeds 10,000 × 10,000 pixels, but iOS devices cap it at 4,096 × 4,096; past the maximum, drawing commands stop working.

On LivreImage that shows up as two numbers: the conversion tools scale down anything over 10,000 px on its longest side, and the background remover returns at most 2,048 px.

What LivreImage requests from the network

Don't take our word for it: test Compress image. Our own code makes these requests:

• Site files: HTML, CSS, JavaScript, fonts and icons, served from livreimage.com.
• On-demand libraries, fetched from public CDNs (cdnjs and jsDelivr, with unpkg as a fallback) only when a tool needs them: the HEIC decoder, PDF, .zip, QR code and the onnxruntime AI engine.
• The AI model for background removal, served from livreimage.com. On first use, engine and model add up to about 7 MB of downloads.
• Supabase: a GET fetches the site's settings, and a POST with a few hundred bytes of text records anonymous usage events — page, language, device type, referring site and, for a conversion, the format, size in bytes and duration. No file name, no pixels.
• Google scripts (Analytics and, if ads are running, AdSense), when the site has them turned on: they follow your answer to the cookie notice; until you accept, Analytics measures without setting cookies.
• The contact form sends only what you type into it.

In a test we ran in September 2026 with analytics and ads switched off, using compress, convert, crop, PDF, .zip, background removal and QR reading produced 45 requests: every one a GET, none with a body. Offline, conversion and a second cutout still worked.

When server-side processing makes sense, and what to ask

Uploading isn't a sign of bad faith: some work doesn't fit in a browser. The authors of the cutout model we use publish two versions, a light one at 4.7 MB and a full one at 176.3 MB. LivreImage runs the light one; a service that wants the full model has good reason to run it on a server: a 176 MB download to cut out one photo on a phone isn't reasonable. The same goes for images too big for your device's memory.

Then the question shifts from “does it upload?” to “what happens next?” California's CCPA requires the businesses it covers to say how long they intend to keep each category of personal information, or the criteria used to decide. EU guidance on the GDPR lists who receives the data and how long it is stored among the things a company must tell you. In the privacy policy, look for:

• A retention period with a number. “Deleted after 1 hour” tells you something; “as long as necessary” doesn't.
• Where files are stored: the country and the hosting provider.
• Who can access them: employees, contractors, partners — and whether your images are used to train AI.
• How to delete a file before the deadline, and whom to ask.

If the policy doesn't answer those four questions, treat the upload as permanent: don't send IDs, photos of kids, or a client's images.