Image Compressor — Free Online Photo Optimizer
Compress JPG, PNG and WebP images directly in your browser. Move the quality slider, compare the original and the compressed copy side by side, then download the result. 100% client-side — your images never leave your browser.
How does image compression work? Lossy image compression shrinks a file by throwing away detail the eye is least likely to notice. JPEG, the format this tool writes, divides the picture into 8x8 pixel blocks, converts each block into frequency coefficients with a discrete cosine transform, then rounds the fine, high-frequency coefficients toward zero. The quality setting controls how coarse that rounding is: lower quality, fewer surviving coefficients, smaller file.
How to Use the Image Compressor
-
Add an image — Drop a JPG, PNG or WebP file onto the upload area, or click to browse. The file is read with
FileReaderand drawn into a canvas in the page; nothing is sent anywhere. - Move the quality slider — The slider runs from 10 to 100 and is passed straight to the JPEG encoder. Every change re-encodes the image immediately, so you can watch the size and the artifacts move together.
- Compare the two previews — Original and compressed sit side by side at the same display size. Zoom the page to inspect flat areas, sky gradients and text edges — that is where JPEG artifacts appear first.
- Check the saved figure — The stats row shows the original bytes, the compressed bytes, and the percentage saved. If the saving is small or negative, the source was already well compressed and there is little left to remove.
-
Download the compressed file — Download Compressed saves the result as
compressed-yourfile.jpg. The pixel dimensions are unchanged — only the encoding is different.
How This Compressor Works
The tool decodes your file into an Image object, draws it onto an HTML canvas at its
original pixel dimensions, and then asks the browser to re-encode that canvas with
canvas.toBlob(callback, 'image/jpeg', quality). The quality argument is the slider value
divided by 100. Everything happens in the page, using the browser's own JPEG encoder — the same one
behind "save image as" in your browser — so there is no upload, no queue and no server-side
processing.
The saving shown in the stats row is measured on the real output, not estimated:
saved % = (1 - compressedBytes / originalBytes) x 100
Two consequences follow from re-encoding through a canvas, and both matter. First, the output is always a JPEG regardless of what you put in, because that is the format the encoder is asked for. Second, the canvas holds nothing but pixels, so every piece of metadata in the original file — EXIF camera data, GPS coordinates, ICC color profiles, copyright fields — is absent from the result. That is useful if you are stripping location data before posting a photo, and a problem if you needed the color profile.
Choosing a quality setting
There is no universally correct value, because how much an image can lose depends entirely on its content. A photograph of foliage hides artifacts well; a screenshot with flat color and small text shows them immediately. The slider positions below are starting points to compare against, not guarantees — always judge by the side-by-side preview.
| Quality | Reasonable for | What to watch for |
|---|---|---|
| 90 – 100 | Archival copies, images that will be edited again, print sources | File size drops little; above 95 the size can climb steeply for no visible gain |
| 75 – 90 | Hero images, product photography, anything viewed full-screen | Soft haloes around high-contrast edges such as text over a photo |
| 55 – 75 | Blog images, thumbnails, email attachments, social uploads | Visible 8x8 blocking in skies, gradients and shadow areas |
| 10 – 55 | Rough previews, placeholders, deliberately degraded output | Obvious blocking and color banding; text becomes hard to read |
What compression cannot fix
Compression only changes how pixels are stored, never how many there are. If a 4000-pixel-wide photo is displayed in a 600-pixel-wide column, the largest possible saving comes from resizing it, not from the quality slider — a resize to the display size typically removes far more bytes than any quality setting, and does so without introducing artifacts. Resize first with the Image Resizer, then compress the smaller version here.
Re-encoding is also generational. Every pass through a lossy encoder discards a little more, and the losses accumulate: compressing an already-compressed JPEG at quality 80 does not restore the first encode, it stacks a second one on top. Always start from the highest-quality copy you have, and keep that original rather than overwriting it.
Because the output is JPEG, transparency is not preserved. A PNG or WebP with an alpha channel will come out with those areas filled rather than transparent, so logos and cut-out product shots should stay as PNG. If you want a smaller file that keeps transparency, convert to WebP with the WebP Converter instead.
Frequently Asked Questions
Image compression rewrites a picture so it occupies fewer bytes. Lossless methods such as PNG's DEFLATE pack the exact same pixels more efficiently and can always be reversed. Lossy methods such as JPEG go further by permanently discarding fine detail that human vision is poor at noticing, which is why they reach much smaller sizes but cannot be undone.
Anything the browser can decode goes in, including JPG, PNG, WebP, GIF and AVIF. The output is always JPEG, because the canvas is re-encoded with image/jpeg. That keeps compatibility as wide as possible, but it also means the download will have a .jpg extension even if you started with a PNG.
Yes — JPEG is a lossy format, so some detail is discarded at every quality setting including 100. At high settings the loss is normally invisible at normal viewing size; at low settings you will see 8x8 blocking and color banding. The side-by-side preview exists so you can decide where that line falls for your particular image rather than trusting a number.
It depends entirely on the source. A large photograph straight off a camera usually shrinks a great deal; an image that has already been optimized may shrink barely at all, and a small PNG icon can even come out larger as a JPEG. The stats row reports the actual result for your file, so treat that figure as the answer rather than any general rule.
No. The file is read locally with FileReader, drawn to a canvas, and re-encoded by the browser. No network request is involved, so private photos, screenshots containing personal data and unreleased artwork never leave the device. Closing the tab discards everything.
Neither survives. A canvas stores pixels only, so EXIF, GPS coordinates and ICC color profiles are dropped during re-encoding — handy for privacy, inconvenient if you needed them. Transparency is lost too because JPEG has no alpha channel, so transparent regions come out filled. Use the Image Metadata Editor if you want to inspect or strip metadata deliberately.
There is no fixed limit in the tool; the practical ceiling is the memory your browser will give a single tab. A very large image has to be held decoded in memory as raw pixels, which is roughly width x height x 4 bytes, so a 50-megapixel photo needs around 200 MB before any encoding starts. On phones and older machines that is where compression tends to fail or the tab reloads.
Resize first, then compress. Cutting the dimensions removes pixels outright and usually saves far more than lowering quality, without introducing artifacts. Compression is the finishing step once the image is already at the size it will actually be displayed. Doing it the other way round wastes the quality you paid for by throwing the pixels away afterwards.
Use Cases
Trimming a Slow Page
A landing page fails its performance budget because the hero photo is a 3 MB camera JPEG. Resize it to the layout width, then compress here until the preview still holds up at full screen.
Getting Under an Attachment Limit
A set of site photos will not fit inside a 10 MB mail limit. Drop the quality a few steps at a time until the total fits, checking that annotations and labels are still readable.
Stripping Location Data Before Posting
Re-encoding through the canvas drops EXIF, including GPS coordinates. Running a phone photo through the compressor removes the location tag along with the extra bytes.
Preparing Catalogue Photography
A shop owner has hundreds of product shots to publish. Testing one representative image here finds the lowest quality setting that survives zoom, then that setting is applied to the batch.
Shrinking Screenshots for a Ticket
Bug trackers and wikis often cap uploads. Compressing a screenshot gets it under the cap, though anything with small UI text is better kept above quality 80 so labels stay legible.
Comparing Encoders Honestly
Before committing a build pipeline to a setting, use the side-by-side preview to see what quality 60 actually looks like on your own images rather than on a sample photo.