Nothing is uploaded, and you can prove it
Every other result for "compress image online" sends your file to a server, which is why those tools have a size cap, a queue, and a privacy policy you did not read. This one decodes and re-encodes in your browser using the same codecs the browser already uses to display images. Open the network tab, compress a photo, and watch the request count stay where it was. There is no size limit because there is no upload to limit.
The work runs in a Web Worker with OffscreenCanvas, off the thread that draws the page. That is not a detail: decoding and re-encoding a 20-megapixel JPEG is a few hundred milliseconds of solid CPU, and on the main thread that is a frozen tab with a spinner that has stopped spinning.
Changing format usually beats changing quality
The comparison line under each file is measured, not estimated: every alternative format is actually encoded at the same quality so the numbers are the real ones. WebP typically lands 25 to 35% under JPEG at matched visual quality, and AVIF another 20% under WebP, which is a larger saving than any quality slider will give you without visible damage.
The catch is support, and it is worth being exact. WebP works everywhere current. AVIF decodes everywhere current but encoding it from a canvas does not exist in every browser, so this page probes by encoding a single pixel and reading the type back. If AVIF is missing from the list, that is why. A canvas asked for a format it cannot write does not raise an error: it quietly returns a PNG, and a tool that trusts its own request hands you a file that is three times larger than the one you started with.
Re-encoding always destroys metadata
There is no "keep EXIF" switch here because there could not be an honest one. The pipeline decodes the file to pixels and encodes those pixels again; EXIF, IPTC, XMP, the colour profile and the GPS coordinates live in the container around the pixels and do not survive the trip. For most uses that is the correct default and a privacy improvement: a holiday photo posted straight from a phone carries the exact coordinates of where it was taken. If you need to see what a file is carrying before it goes, the EXIF viewer reads it without modifying anything.
The colour profile is the part that occasionally bites. A photo tagged Display P3 re-encoded here comes out untagged, which browsers then read as sRGB, and a saturated red can shift visibly. If you are compressing wide-gamut photography for print, this is not the tool.
Common problems
- The file got bigger. Usually a PNG screenshot: PNG is lossless and already efficient for flat colour, and re-encoding it as PNG cannot beat what an optimiser already did. Convert it to WebP instead, where a screenshot commonly drops 60%.
- A HEIC from an iPhone will not open. Only Safari can decode HEIC, so outside it the file fails here rather than pretending. Setting the phone's camera to "Most Compatible" produces JPEG instead.
- A transparent PNG came out with a white background. JPEG has no alpha channel, so the transparency has to become something. It becomes white here rather than the black most canvas pipelines default to. Choose WebP or PNG to keep it.
- An animated GIF became a still. A canvas decodes one frame. Converting an animation through this page keeps the first frame and nothing else.
Frequently asked questions
What quality should I use?
75 for photographs on the web, which is where JPEG and WebP sit on the curve just before artefacts become visible at normal viewing size. Below 60 the blocking around high-contrast edges shows. Above 90 the file grows quickly for a difference nobody can see on a screen. Quality does nothing at all for PNG, which is lossless, so the slider is inert there.
Is there a file size limit?
No upload limit, since there is no upload. The real limit is your device's memory: a decoded image occupies width × height × 4 bytes regardless of how small the file was, so a 50-megapixel photo is 200 MB of RAM before anything is encoded. Thirty files at a time is the batch cap for that reason.
Why is the ZIP not compressed?
Because it would be pointless. Every file in it is an already-compressed image, and deflating a JPEG saves a fraction of a percent for a full pass over the bytes. The archive is written in store mode, which is a valid ZIP that every operating system opens natively.
Does compressing twice make it smaller again?
Smaller, and worse. Lossy re-encoding is generational: each pass quantises the previous pass's artefacts along with the image. Always compress from the original, never from an output.