Guide
Image Compress re-encodes a batch of JPG, PNG and WebP files (plus anything else the browser can decode, such as GIF, BMP and HEIC) into smaller files inside the browser: encode once at a fixed quality, or give the tool a target size in KB and let it iterate towards that, and cap the longest edge while you are at it. Images are never uploaded.
Updated 2026-09-094 sources12 min read
Image Compress re-encodes a batch of JPG, PNG and WebP files (plus anything else the browser can decode, such as GIF, BMP and HEIC) into smaller files inside the browser: encode once at a fixed quality, or give the tool a target size in KB and let it iterate towards that, and cap the longest edge while you are at it. Images are never uploaded.
It exists for the everyday case where a file is just over a limit: a form that only accepts photos under 500 KB, an email attachment that bounces, web images that slow a page down, a phone gallery of several thousand 3–5 MB originals to archive. When the run finishes you get before-and-after totals, a per-image comparison preview and a zip download.
It is not magic. For lossy formats (JPEG, WebP), “compression” means discarding detail the eye barely notices; for a lossless format (PNG) it can do almost nothing, and shrinking the pixel dimensions is the only real lever. Once that is clear, every switch makes sense — the How it works section below goes through the mechanics, and other image tools on this site link back here whenever format and file size come up.
original size → new size plus a percentage; the eye icon toggles between “compressed” and “original”; download files one by one or “Download all as zip”.
Five different kinds of image through four settings of the same run, all measured:
Input Original Quality 0.75 Quality 0.50 0.75 + longest edge 1920 Target 200 KB
photo-3000x4000.jpg (photo) 1.3 MB 1.1 MB 294 KB 90 KB (→1440×1920) 178 KB
screenshot-1920x1080.png 21.7 KB 14.1 KB 14.1 KB 14.1 KB 14.1 KB
screenshot-1920x1080.jpg 71.9 KB 57.6 KB 49.3 KB 57.6 KB 69.1 KB
scan-1600x1200.webp 342.5 KB 282.3 KB 164 KB 282.3 KB 153.4 KB
logo-400x300.gif → .png 5 KB 4.8 KB 4.8 KB 4.8 KB 4.8 KB
Total 1.7 MB 1.4 MB 526 KB 449 KB 419 KBDrag the quality slider to see the size and a magnified detail of the same 3000 × 4000 photo (measured): 1.0 and 0.9 both give 1.2 MB (a quality above the original's is stepped down automatically until the output is just under the original), 0.75 → 1.1 MB, 0.5 → 294 KB, 0.3 → 117 KB, 0.1 → 81 KB; below 0.5 blocking and ringing start to appear at the edges.
“Target 200 KB” brings the photo down to 178 KB, yet it barely touches a 72 KB JPG that is already below the target. Some patterns are worth noting: PNG keeps the same size under all four settings, because the quality slider does nothing for it; and scaling the photo from 3000 × 4000 to a 1920 long edge leaves it at 7% of the original, far more effective than dropping the quality from 0.75 to 0.5.
An uncompressed image takes 3 bytes per pixel, so 3000 × 4000 is 36 MB. Every image format is doing the same job: describing those pixels with fewer bits. There are only two routes — lossless (bit-for-bit identical after decoding) and lossy (throwing away information the eye barely registers in exchange for a large drop in size).
JPEG first converts RGB into a luminance channel plus two chroma channels, and the chroma is usually subsampled to a quarter of the resolution. The picture is then cut into 8 × 8 blocks for a discrete cosine transform (DCT), giving 64 frequency coefficients, and then comes the crucial step: quantisation, where each coefficient is divided by the matching number in a quantisation table and rounded. The quality parameter (0.1–1 here, encoder values 10–100) decides how coarse that table is: lower quality means larger divisors, so most high-frequency coefficients collapse to zero and the entropy coder squeezes that long run of zeros into almost nothing.
That is why quality is not linear: going from 0.75 to 0.5 takes the photo above from 1.1 MB to 294 KB because high-frequency detail is wiped out over that range, while going from 0.9 to 1.0 doubles the size for a difference the eye can hardly see. For most photos 0.7–0.8 is the balance point between looks and size, and content like text screenshots is more sensitive to JPEG ringing, so PNG is the better choice there.
Lossy WebP works the same way (prediction + transform + quantisation) and is usually 25%–35% smaller than JPEG at a comparable look; this tool keeps WebP in and WebP out, with the quality slider equally effective.
PNG is lossless: each row of pixels is prediction-filtered and then compressed with DEFLATE (the same algorithm as zip). There is no “how much to throw away” knob — the specification has no quality parameter at all, and browser canvas encoders ignore one. Two things follow. First, PNG compresses large flat areas, text and lines extremely well (the 1920 × 1080 screenshot above is only 14 KB) and photos and noise hardly at all. Second, the only ways to make a PNG smaller are to reduce the pixel dimensions or to switch to a lossy format (use “Image Converter”).
Incidentally, the PNG going from 21.7 KB to 14.1 KB above is not lossy: the browser's PNG encoder simply picked better filters and a better compression level than the tool that produced the original.
This tool — and every other image tool on this site — re-encodes through the browser canvas: decode → draw to canvas → canvas.toBlob(type, quality). Three consequences follow. First, the encoder comes from the browser, so the same parameter can produce a file one or two tenths different in Chrome, Safari and Firefox. Second, a canvas is a pixel array with no metadata attached: EXIF (shooting parameters, GPS) and colour profiles never reach the output, and the orientation tag is applied to the pixels and then discarded, so a portrait shot does not end up sideways. Third, JPEG has no alpha channel, so transparent areas are filled with white.
Target mode starts encoding at quality 0.95; if the result is over the target it multiplies width and height by 0.95 and the quality by 0.95 and encodes again, up to 10 rounds. After 10 rounds the longest edge can be down to 60% (36% of the pixels) with a quality floor around 0.57; if it is still over, the last round is delivered — which is why the interface says it “gets as close as it can”. For high-resolution photos, shrinking the edges contributes more than lowering quality, so photos from target mode often end up smaller and sharper than “quality 0.5”.
If the first encode comes out larger than the original file, the library multiplies the quality by 0.95 and tries again, up to 10 rounds, until the output is below the original — which is why the photo above lands on 1.2 MB with the slider at both 1.0 and 0.9. If it is still not smaller after 10 rounds, the tool keeps the original file and marks it “Original is already small enough, kept as is”, which is common with a well-optimised PNG.
_compressed suffix.Phone-shot application material comes in at 3–4 MB a piece. Choose “Target size” and enter 500, or simply turn on “Cap the longest edge at 1920” with quality 0.75, then check the size on each result card a few seconds later.
Drop the batch in, set a 1600 longest edge and quality 0.8 in one pass, and send the zip to whoever runs the shop; if the white-background PNGs are still too big, convert them to WebP with “Image Converter”.
Run PNG screenshots through this tool first (often 20%–40% smaller, losslessly) so text edges stay crisp; do not convert them to JPEG.
Several thousand originals can take tens of GB. A 2560 longest edge and quality 0.8 bring that down to about a tenth — but EXIF is lost, so save the originals separately if you need the capture times.
PNG is lossless and has no adjustable quality. This tool can only re-encode it once through the browser's encoder, and the gain depends on how well the original was optimised. To shrink it noticeably, reduce the dimensions or convert it to WebP / JPEG.
The original was already well compressed, or the quality you chose is above the quality it was encoded at. In that case the tool keeps the original file unchanged.
There are at most 10 iterations, and a very high-resolution image may not reach the target within them. Turn on “Cap the longest edge” and run it again, or set the target slightly below the limit.
No. The orientation tag is applied to the pixels before encoding, so the output has the same orientation in any viewer; the tag itself is removed along with the rest of the EXIF.
Yes — HEIC is decoded to JPEG locally and then compressed, with no network involved. There is no limit on the number, only on browser memory: dozens of 4000 px photos are fine, while several hundred are better done in batches.
Decoding, scaling and encoding all happen inside your browser; images are never uploaded and the tool works offline. The output carries no EXIF or GPS data. Read more in the privacy policy.
HTMLCanvasElement.toBlob() — the type and quality parameters, and why PNG ignores quality: https://developer.mozilla.org/zh-CN/docs/Web/API/HTMLCanvasElement/toBlob（访问日期：2026-09-09）maxSizeMB, initialQuality, maxWidthOrHeight and maxIteration: https://github.com/Donaldcwl/browser-image-compression（访问日期：2026-09-09）Updated 2026-09-09
Batch-compress JPG/PNG/WebP by quality or target size, entirely in the browser