Image compressor
Drop in one or more JPEG, PNG or WebP images. Pick an output format, a quality level, and an optional maximum size, and this page decodes, resizes and re-encodes each one right where it sits — nothing is ever uploaded.
How it works
There is no proprietary compression algorithm behind this page — it uses the same two browser features every client-side image tool is built on:
- Decode.
createImageBitmap(file)asks the browser to decode your image straight from the file, without a round trip through a data URL or a visible<img>element. - Draw. The decoded bitmap is drawn onto an in-memory
<canvas>, sized to either the original dimensions or the downscaled ones if a max width/height was set. - Re-encode.
canvas.toBlob(callback, type, quality)hands that pixel grid back to the browser's own image encoder, which returns a new compressed file in the format and quality you chose.
Every step happens with browser-native APIs that ship in Chrome, Firefox, Safari and Edge. What you are testing here is genuinely your own browser's built-in encoder — the same one a native app on your device would call into — not a server, and not a black box.
JPEG vs WebP vs PNG — when each one wins
The right output format depends on what is actually in the picture, not on habit:
| Format | Compression | Transparency | Best for |
|---|---|---|---|
| JPEG | Lossy only | No | Photos and photo-like images with soft gradients; universally supported |
| WebP | Lossy or lossless | Yes | Photos where you want smaller files than JPEG at the same visual quality, and photos that also need transparency |
| PNG | Lossless only | Yes | Screenshots, line art, logos and UI mockups — anything with sharp edges, flat colour or text |
Running a photo through JPEG or WebP at a sensible quality setting typically shrinks it by 70–90% with no visible difference at normal viewing sizes, because a camera photo's raw pixel data is far more precise than the eye can actually use. A UI screenshot behaves the opposite way: JPEG's lossy blur smears crisp text and hard edges, and produces an objectively worse-looking, and often larger, file than the PNG it started as. Keep screenshots and logos as PNG (or lossless WebP); compress photos as JPEG or lossy WebP.
Why quality is a trade-off, not a setting to maximise
The quality slider controls how aggressively the JPEG or WebP encoder discards information the human eye is least sensitive to — mostly fine colour detail, since vision resolves brightness far more precisely than colour. At quality 1.0 that discarding is minimal and the file stays large; at quality 0.1 it is severe and file size drops a lot, but so does fidelity.
The relationship is not a straight line. Moving from 1.0 down to about 0.8 usually costs almost nothing visible while cutting file size substantially — that is the easy, close-to-free saving. Below roughly 0.5 the curve gets much steeper: each further step down buys progressively less size reduction for progressively more visible artifacting (blocky squares around hard edges, banding in skies and gradients). There is no single correct number; it depends on the image and how it will be viewed. A thumbnail nobody will zoom into can sit much lower than a photo destined for print.
Metadata and EXIF are dropped — on purpose, mostly
A <canvas> element only ever stores pixel colour values. There is no field in it for a camera model, a capture timestamp, a colour profile, or a GPS coordinate, so none of that metadata survives the decode-draw-re-encode round trip this tool performs — whether or not you wanted it to.
The privacy upside: photos taken on a phone frequently carry an embedded GPS location in their EXIF data, which is one of the more surprising ways people accidentally publish where a picture was taken. Running an image through this tool strips that automatically, with nothing to configure.
The caveat: EXIF orientation is metadata too, and it goes with everything else. Some cameras save the sensor's raw, unrotated pixels and rely on an orientation flag to tell software "display this rotated 90°" rather than physically rotating the pixel data. Browsers generally read that flag while decoding and draw the bitmap already upright, so what lands in the preview above is what actually gets encoded — but the tag itself does not travel to the output file, because nothing in EXIF does. If a source photo shows up sideways in the preview, that reflects a decoding quirk on that specific file, and the compressed copy will keep whatever orientation the preview showed.
Honest limits
- Not a dedicated encoder. Browsers ship a general-purpose JPEG and WebP encoder tuned for speed and broad compatibility, not the smallest possible file. Specialist encoders such as mozjpeg or a fully-tuned WebP/AVIF pipeline can often shave an additional 5–15% off file size at matching visual quality, at the cost of being much slower and needing dedicated software rather than a browser tab.
- PNG only ever compresses by shrinking dimensions. There is no lossy PNG mode in
canvas.toBlob, and no palette-reduction step either, so a PNG that is already at the size you want to display it at will not get meaningfully smaller here. Converting it to WebP, or downscaling it, are the two things this tool can actually do for a PNG. - Decoding depends on your browser, not this tool. Whether a given file opens at all — HEIC/HEIF straight off an iPhone is the common case — depends entirely on whether your browser's built-in image codecs support it. If a file fails here, the fix is usually to convert it with the software that produced it, or open it in a browser that does support the format, rather than anything this page can control.
- Very large batches use real memory. Each image is decoded and drawn at full resolution before being resized, so dozens of very high-resolution originals processed at once can strain memory on an older device. Downscaling with the max-dimension setting reduces that pressure considerably.
Use cases
- Getting under an upload size limit for a marketplace listing, a job application, or a web form that rejects anything over a few megabytes.
- Shrinking page weight before adding photos to a blog post or product page, where every extra megabyte is extra load time for every visitor.
- Preparing a batch of phone photos for sharing without also sharing the GPS coordinates and camera details embedded in the originals.
- Converting between formats — turning a PNG screenshot bank into WebP for a smaller footprint, or a WebP image into JPEG for software that can't open WebP yet.
Frequently asked questions
Does compressing an image here upload it anywhere?
No. The file is decoded, resized and re-encoded entirely inside your browser using the Canvas API. Nothing about the image — not the pixels, not the filename — is ever sent to a server. You can disconnect from the internet after the page has loaded and the tool keeps working.
Why did my PNG barely get any smaller?
Because PNG is a lossless format and the browser's canvas re-encoder has no lossy PNG mode — there is no quality knob to turn down. The only way this tool shrinks a PNG is by reducing its pixel dimensions with the max width/height setting. A screenshot or logo saved as PNG mostly needs a dedicated palette-reduction tool, or converting to WebP, to get meaningfully smaller.
JPEG or WebP — which should I pick?
WebP is normally the better default: at the same visual quality it is usually noticeably smaller than JPEG, and unlike JPEG it supports transparency. Pick JPEG instead only if the image has to open in software with no WebP support — some older editing tools and a handful of print workflows still don't have it.
What quality setting should I use?
0.75 to 0.85 is where most photos stop losing visible detail while still shrinking a lot. Go down to 0.5–0.6 for thumbnails or images nobody will zoom into, and keep 0.9 or higher for anything you plan to print or crop later. Below about 0.4, compression artifacts such as blockiness and colour banding become obvious on most photos.
Will this fix a photo that's the wrong way up?
It uses your browser's own image decoder, which normally reads the file's embedded EXIF orientation tag and draws the pixels upright automatically — so if the preview above looks correct, the file you download will too. What it can't do is add rotation information after the fact: the compressed file carries no EXIF at all, orientation tag included, so whatever you see in the preview is exactly what you get.
Does this remove GPS location and other metadata from my photos?
Yes, as a side effect of how canvas works rather than a feature built specifically for it: a canvas only ever holds pixel colour values, never surrounding file metadata, so camera model, capture date, colour profile and any embedded GPS coordinates are all gone from the re-encoded file.
Is there a limit to how many images or how large a file I can compress?
No limit is enforced by this page, but there is a practical one: everything happens in your browser's memory, so a batch of very large, high-resolution originals can slow down or stall an older device. The tool already processes images one at a time rather than all at once; using the max-dimension setting for huge originals keeps memory use manageable too.
Why does a JPEG I re-compress here sometimes look worse than the original?
JPEG is lossy every time it is encoded, so re-saving a JPEG that has already been compressed once stacks a second round of quality loss on top of the first. This is generational loss, and it is true of every JPEG encoder, not something specific to this tool. If you still have the original, uncompressed source, compress from that instead of from an already-compressed copy.
Can I use this on my phone?
Yes — it is the same page and the same browser APIs, just running on a phone's browser instead of a desktop one. Very large photos, which is now typical straight off a phone camera, take a little longer to process on mobile hardware, but the result is identical.