Image Compressor & Resizer

Lossy vs lossless — what actually shrinks a file

Two levers control an image's size: how many pixels it has and how those pixels are encoded. Dropping the pixel count — a smaller max width or a lower scale — is usually the single biggest saving, because file size roughly tracks the pixel area, not the width. A 4000 px-wide photo resized to 1600 px keeps only (1600/4000)² ≈ 16% of its pixels, so it starts more than six times smaller before any quality tuning.

Lossy formats (JPEG and WebP) then discard the fine detail the eye is least likely to miss; the quality slider decides how aggressive that is. Lossless PNG keeps every pixel exactly, so it never degrades — but it also compresses photographs far less, which is why a photo saved as PNG often ends up larger than the JPEG you started with.

Worked example: a phone photo for the web

Take a typical 12-megapixel phone shot, 4000×3000 px, saved by the camera as a JPEG at roughly 4.2 MB. You want it for a blog post where it will display about 800 px wide. A representative path through this tool:

Your exact bytes will differ with the photo's content — a busy landscape compresses less than a plain portrait — but the shape holds: resizing did most of the work, and the last push from quality 0.80 to 0.60 saves far less than the first resize did while costing visible quality. The before → after sizes here update the instant you move any control, so drag the quality slider until you see the artefacts, then back off one notch.

Compressing to a target size — how the KB mode works

When you type a number into Target size, the tool stops using the quality slider and searches for the right quality itself. JPEG and WebP encoders take a quality parameter from 0.01 to 1.00, and file size grows with it, so the search can bisect: encode at quality 0.51 — over the target? try 0.25; under? try 0.76 — halving the range each round. A 1–100 quality range needs at most 7 trial encodes, all on your own device, and lands on the highest quality that still fits. The result line shows the exact bytes achieved and the quality used, so nothing is hidden.

The guarantee is deliberately narrow and honest: at or under the target, as close as quality alone allows. Quality is the only knob the search turns — your dimensions stay exactly what Max width and Scale say. That also means a target can be genuinely unreachable: a 4000×3000 photo has too many pixels to fit in 30 KB at any quality. When even minimum quality overshoots, the tool tells you so in plain words instead of handing you an over-target file, and points you at the stronger lever — lower Max width or Scale first, then the same target usually becomes easy. Two caveats: the byte counts are real encodes, not estimates, so very large images take a moment; and PNG is excluded, because it is lossless and has no quality parameter to search — pick JPEG or WebP for a byte budget and accept that some fine detail is discarded.

A whole set at once — what the batch actually does

Drop twelve holiday photos and all twelve are compressed under one set of settings: the same max width, the same scale, the same format, and either the same quality or the same KB target. That is the point of a batch — a folder of pictures for one blog post or one email wants one consistent treatment, not twelve separate decisions. Each file still gets its own row with its own numbers, because a batch average hides the one photo that barely shrank.

Three details are worth knowing before you drop forty files:

• Files are processed one at a time, not all at once. A decoded 12-megapixel photo is about 48 MB of raw RGBA pixels in memory — forty of them at once is roughly 1.9 GB, which is how a browser tab dies. Here each image is decoded, drawn and then released before the next one is opened, so the tab holds one decoded picture at a time however long the queue is. It does mean a big batch takes visible seconds; the rows fill in from the top as it goes.
• The zip is stored, not compressed. "Download all (.zip)" appears once two files have finished and packs them with zip's store method — no deflate. That is deliberate: JPEG, WebP and PNG bytes are already compressed (PNG is internally deflate; JPEG is Huffman-coded DCT), so deflating them again typically saves a percent or two, sometimes adds bytes, and costs real time on a large set. Every unzip tool on every platform reads stored entries.
• Colliding names are numbered, not overwritten. Output names are the original stem plus the output width — holiday-1600px.jpg. Two files called holiday.jpg from different folders, or a holiday.png and a holiday.jpg both saved as JPEG, would land on the same name; the second and third get holiday-1600px-2.jpg and -3.jpg. Two identical names inside one archive is a silently corrupt download, where most unzip tools show one file and quietly drop the other.

A file the browser cannot decode — HEIC from an iPhone is by far the most common, because most browsers cannot read Apple's format at all — stays on screen as a named error row that says why, and is left out of the zip. It is never silently missing from the archive. On the phone, Settings → Camera → Formats → Most Compatible makes the camera save JPEG instead.

JPEG vs PNG vs WebP

For the same visible quality, WebP is typically 25–35% smaller than JPEG on photos and, unlike JPEG, can store transparency. Every current browser displays WebP, so for anything web-facing it is usually the right pick. Choose JPEG only when a file must open in older desktop software or email clients that still don't understand WebP. Reach for PNG for logos, screenshots, line art and anything with sharp edges, text or an alpha channel — but never for photos, where its lossless encoding balloons the file.

Common mistakes

• Resizing up never restores detail. Enlarging a small image (scale above the source, or a max width bigger than the original) just interpolates new pixels from existing ones — it looks softer, not sharper. This tool only downsizes; it will not upscale past the source.
• Re-saving a JPEG stacks generation loss. A JPEG is already lossy; decoding and re-encoding it as JPEG adds a fresh round of artefacts on top of the old ones, so edges muddy even at the same quality number. Shrink by reducing dimensions, not by repeatedly re-saving.
• PNG is not a photo compressor. Saving a photograph as PNG usually makes it bigger, because millions of subtly different pixels defeat lossless packing.
• Quality 1.00 is rarely worth it. The jump from 0.85 to 1.00 can double the file for detail almost nobody can see. Around 0.75–0.85 is the sweet spot for most photos.

Honest limits

Everything happens on your own device through the browser's Canvas API and canvas.toBlob — no upload and no server — private photos, screenshots and scans stay in the tab. That same Canvas path strips all metadata: EXIF, GPS coordinates, camera settings and the embedded colour profile are discarded. That is usually a privacy win, but it means an image relying on EXIF orientation may appear rotated, and wide-gamut photos are treated as sRGB. It re-encodes with the browser's built-in encoder, so it does not run advanced optimisers like MozJPEG or a PNG palette-quantiser and will not beat a dedicated command-line tool byte-for-byte. Very large images (tens of megapixels) need a lot of memory to decode, animated GIFs are flattened to a single frame, and on a rare old browser without WebP encoding it falls back to PNG and tells you. A batch is processed one file at a time and each decoded image is released before the next, so a long queue is slow rather than fatal — but it is still your device doing the work, and a KB target multiplies that, because each file is then encoded up to seven times while the search finds its quality.