Compress images without uploading them: how to check

A browser can resize and encode an image without sending it to a server. That’s how PicThin works: your browser reads the file you choose, processes it on your device, and gives you a copy to download. Your original and processed images aren’t uploaded to PicThin.

Local processing still needs an app to run

When you open PicThin, your browser downloads the page and its code. It may fetch more code when you first select an image. The compression worker is served by PicThin too. Downloading that code is different from sending your photo to a server.

The site also uses visit analytics and anonymous tool events. Tool events describe the action, tool, output format, image count, processing time, and error category. They do not contain image data, filenames, or previews. If you send feedback, your message, optional email, and current page are sent to the server. That’s separate from processing an image.

Inspect a test run before using a private photo

Use a harmless sample first. You can download our landscape PNG and try it in the image compressor with JPG output selected.

1. Open developer tools in desktop Chrome or Edge and choose Network. Keep recording enabled, select All, and clear the existing list.
2. Choose the sample, let it finish processing, and download the result.
3. Review the requests made during those steps. Check their destinations, types, and what initiated them.
4. For requests that send data, inspect the Payload. A request to /api/tool-events, for example, should contain a few event fields, not a file or encoded image.
5. Review the whole recording. A missing filename alone proves very little. If extensions are adding noise, repeat the test in a separate browser profile with extensions disabled.

A preview URL beginning with blob: refers to an object available to the browser. It isn’t an upload address. However, seeing a blob URL doesn’t prove that a site isn’t sending the same image somewhere else.

Try processing another image while offline

First finish one compression with the format you intend to use. This gives the browser a chance to load the necessary code. Keep the page open, then disconnect from the internet or select Offline in the Network panel.

Choose the sample again, change the quality, and check that you can generate, preview, and download a new result. Restore the connection when you’re done. If a format you haven’t used fails to start offline, load it online first and repeat the test.

This checks whether that operation needs a server to do the work. It is not a complete security audit, and it cannot by itself rule out a site sending data after reconnecting. Use it alongside the request inspection, rather than treating an offline test as a universal privacy guarantee.

A private workflow doesn’t make every photo safe to share

Names, faces, document numbers, and messages can still be visible in a compressed image. Compression doesn’t redact them. Files may also contain location or camera metadata. Before publishing a photo, consider making a new copy with the EXIF and GPS removal tool and checking the downloaded result.

Don’t assume ordinary compression strips metadata: some tools keep the original file when it’s already small enough. Local processing also cannot protect a device controlled by malicious software or an extension. Keep your original, review the copy you plan to share, and remove files you no longer need.

Pick a tool for the job

• Compress a JPG for an everyday photo.
• Compress a PNG for a graphic that needs transparency.
• Set a file size limit for a form, then check its format and dimension requirements too.

For a tour of the Network panel, see Chrome’s official guide. You can also read how PicThin works and open the privacy notice in the footer.