How our compressor works

1. The file is read from your disk into the memory of the browser tab. This is a local read — the same thing that happens when you open a file in any application.
2. createImageBitmap decodes it into raw pixels, applying the EXIF orientation so the image is the right way up.
3. The bitmap is drawn to a canvas at the output dimensions, using high-quality resampling.
4. canvas.toBlob encodes it at your chosen format and quality.
5. The resulting blob is turned into a temporary URL and offered to you as a download.

Steps two to four run inside a Web Worker on a separate thread, which is why the interface stays responsive while a large batch processes. No step involves a network request.

Encoders do not accept a file size — they accept a quality, and the size falls out of it. So hitting a specific number means searching for it.

The tool encodes at a mid-range quality, measures the result, and moves the quality up or down depending on whether it came in under or over your limit. It repeats that, halving the remaining range each time, until it finds the highest quality that still fits. That converges in about eight passes.

If nothing fits even at minimum quality and you have allowed the dimensions to change, it scales the image down by a fifth and searches again. If you have locked the dimensions, it stops and tells you the target could not be met — rather than handing you an oversized file and staying quiet about it.

You should not take our word for it. Two checks, neither requiring any technical skill:

The offline test. Load any tool page, then disconnect from the internet — Airplane Mode, or unplug the network. Now compress an image. It works. A tool that uploaded your file could not.

The network panel. Open your browser's developer tools, go to the Network tab, and compress an image while watching it. You will see no upload request, because there is nothing to upload to.

These checks work on any tool, not just this one, and they are the fastest way to tell what a compressor is actually doing.

Being honest about the trade matters more than the claim itself.

• No HEIC, RAW or TIFF. Browsers cannot decode them. We will not ship a tool that fails silently on the file you just chose.
• No AVIF or JPEG XL output. Browsers cannot write them — and a canvas asked for a format it cannot produce silently returns a PNG, which would mean handing you a mislabelled file.
• No animated GIF or WebP. A canvas decodes only the first frame, so a "GIF compressor" built this way would destroy your animation.
• A few per cent behind MozJPEG. A server running a better encoder would produce slightly smaller JPEGs than your browser does.
• Memory limits. Each image is held uncompressed while processed, so very large batches can exhaust a browser tab, particularly on a phone.
• Colour space. A canvas works in sRGB, so wide-gamut images are converted. Correct for the web, wrong for print masters.

Where those matter, desktop software or a server-side service is the better tool, and we say so on the relevant pages rather than pretending the gaps do not exist.

The site itself is an ordinary website, and it behaves like one.

Our host records standard web server logs — IP address, timestamp, requested URL, referrer, user agent — used for security and diagnosing faults. If you send a message through the contact form, we store what you typed so we can reply. Analytics, where configured, counts page views.

None of that touches your images, because your images never arrive. The privacy policy sets it out in full.

Running a site that does its computing on your device is unusually cheap: we are not paying to process your images, so there is no per-image cost to recover and no reason to meter usage.

Hosting is covered by advertising placed below the tool, never above it. There is no premium tier, because adding one would mean deliberately withholding something that already works.