Image Compression: Formats Compared, Quality Explained, and Free Tools That Work Locally

Image compression is the thing everyone needs and almost nobody understands. You upload a 5MB photo, the tool says "compressed to 200KB," and you download it hoping it doesn't look terrible. Sometimes it does. Sometimes you can't tell the difference. The difference is usually the format choice, the quality setting, and whether the tool is doing something smart or just re-encoding at quality 60 and calling it a day.

This guide covers what actually happens when you compress an image, which format to choose for which situation, how to batch compress hundreds of images without uploading them to a server, and how binary search compression works to hit an exact target file size.

The four image formats that matter for the web

There are dozens of image formats. For web and digital use, four matter. Here's what each one actually does.

JPEG — the 30-year workhorse

JPEG compression works by discarding information the human eye is bad at perceiving. It converts the image from RGB to YCbCr (luminance + two color channels), downsamples the color channels (because we're more sensitive to brightness detail than color detail), splits the image into 8×8 pixel blocks, applies a Discrete Cosine Transform to each block (converting spatial data into frequency data), and then quantizes the frequency coefficients — throwing away high-frequency details based on a quality table. At quality 100, almost nothing is discarded. At quality 60, a lot is. At quality 20, the image looks like a mosaic.

Best for: Photographs, screenshots, complex images with gradients, anything where you need a small file and can tolerate invisible quality loss. JPEG at quality 85 is visually indistinguishable from the original for most photos and achieves 5-15x compression.

Worst for: Text, logos, line art, images with sharp edges. JPEG creates "ringing artifacts" — ghostly halos around high-contrast edges. Never save a screenshot of text as JPEG.

Doesn't support: Transparency. JPEG has no alpha channel. If you need transparency, use PNG or WebP.

PNG — lossless, but large

PNG uses DEFLATE compression (same algorithm as ZIP). It's lossless — every pixel is preserved exactly. For photos, this means huge files: a 12MP photo that's 3MB as JPEG might be 18MB as PNG. For graphics with large areas of solid color (logos, icons, screenshots of UI), PNG can be very efficient because DEFLATE excels at compressing repeated patterns.

Best for: Logos, icons, screenshots, images with text, anything needing transparency, images that will be edited and re-saved multiple times (lossless means no generation loss).

Worst for: Photographs. 5-10x larger than equivalent-quality JPEG.

PNG-8 vs PNG-24: PNG-8 uses a 256-color palette and is much smaller. PNG-24 supports 16 million colors but is larger. If your image has fewer than 256 colors, save as PNG-8. Most "PNG compressors" don't offer this option, but GIMP and ImageMagick do.

WebP — the middle ground nobody adopted fast enough

Google released WebP in 2010. It supports both lossy (like JPEG but 25-35% smaller at equivalent quality) and lossless (like PNG but 26% smaller on average). It supports transparency and animation. As of 2026, every major browser supports WebP. It should have replaced JPEG and PNG by now, but inertia is powerful.

Best for: Everything on the web. Photos, graphics, transparency, animation. If you control the platform where images will be displayed and it's a modern browser, WebP is the right default.

Worst for: Print (not widely supported by printers), sharing with people who use very old software (pre-2020).

Tradeoff: WebP encoding is slower than JPEG because it uses more sophisticated compression (predictive coding, block-adaptive quantization). For batch processing thousands of images, the encoding time difference adds up.

AVIF — the future, if licensing doesn't kill it

AVIF is based on the AV1 video codec. It achieves 50% smaller files than JPEG at equivalent quality, supports HDR, wide color gamut, transparency, and animation. The compression efficiency is genuinely remarkable — a photo that's 1MB as JPEG at quality 85 might be 350KB as AVIF at equivalent quality. Chrome, Firefox, and Safari all support it. It's the obvious successor to both JPEG and PNG for web use.

The catch: encoding AVIF is computationally expensive. A batch of 100 photos might take minutes to encode as AVIF vs seconds for JPEG. It makes sense for static assets (your website's hero images, product photos that won't change) but not for real-time user-generated content. Also, the AV1 patent licensing situation has been contentious, though the Alliance for Open Media's licensing terms have stabilized since 2024.

Best for: Production web assets that will be served many times. The encoding cost is paid once; the bandwidth savings accrue forever.

Worst for: Quick one-off compressions. The encoding time isn't worth it for a single use.

Format choice flowchart

Need transparency? → WebP or PNG (WebP if you control the platform, PNG for maximum compatibility)

Photo for web, no transparency? → WebP or AVIF (AVIF for static assets, WebP for user uploads)

Photo for email/sharing with anyone? → JPEG at quality 80-85. Compatible with everything, good enough quality, small enough to email.

Logo/icon/graphic? → SVG if it's vector art, PNG if it's raster. Don't use JPEG for graphics with sharp edges.

Screenshot? → PNG. JPEG ruins text legibility.

Print? → JPEG at maximum quality, or TIFF. Print workflows don't use WebP or AVIF.

How quality settings actually translate to file size

The relationship between quality setting (0-100) and file size is not linear. Quality 80 is not "80% as good as quality 100." Here's what actually happens:

• 100-95: Huge files, imperceptible quality gain over 90. You're storing noise. Only use these for archival masters.
• 90-80: The sweet spot for most photos. 5-15x compression vs original. Visually indistinguishable from 100 for normal viewing distances.
• 80-60: Visible artifacts if you zoom in, but fine for thumbnails, social media previews, and images displayed at less than full resolution.
• 60-40: Noticeable quality loss at full resolution. Blocking artifacts, color banding in gradients, blurred text. Acceptable for very small thumbnails only.
• Below 40: The image is visibly degraded. Use only for placeholder images or extreme bandwidth constraints.

The exact threshold where quality loss becomes visible depends on the image content. A photo of a forest with lots of texture and no sharp edges will look fine at quality 60. A photo of text or a UI mockup will look terrible at quality 80 because JPEG's block-based compression creates artifacts at high-contrast edges.

Dimensions matter more than quality for file size

File size roughly scales with pixel count. A 4000×3000 image at quality 85 is about 4x larger than a 2000×1500 image at quality 85. If you're displaying an image at 800px wide on a website, there's no reason to serve a 4000px version. Resize before compressing.

Common dimension targets:

• Full-width website hero image: 2400px wide, compressed to 200-400KB
• Blog post inline image: 1200px wide, compressed to 100-200KB
• Product thumbnail (ecommerce): 800px square, compressed to 50-100KB
• Social media post: 1080px (Instagram), 1200px (Twitter/X), compressed to 150-300KB
• Email inline image: 600px wide, compressed to under 100KB (many email clients block images >1MB)

Batch compression: how to do 500 images without uploading any of them

Cloud-based batch compressors are convenient. Drop a folder, wait, download a ZIP. But you're uploading every image in that folder to a server. If those are product photos for an unreleased line, client photos from a wedding shoot, or anything sensitive, that's a problem.

Browser-based batch compression solves this. The BackgroundDelete image compressor handles up to 50 images at once, all in the browser. Each image runs through a binary search algorithm that tests different quality levels to hit a target file size. If you set the target at 200KB, the tool tries quality 0.5, checks if the result is under 200KB, adjusts up or down, and converges on the right quality level within 5-8 iterations. It takes 3-10 seconds per image depending on resolution and format.

For larger batches (hundreds of images), the browser approach has a practical ceiling around 50 images per batch due to memory constraints. For industrial-scale compression, ImageMagick from the command line is the answer:

# Resize all JPEGs in a folder to 2000px wide, quality 85
mogrify -resize 2000x -quality 85 *.jpg

# Convert all PNGs in a folder to JPEG at quality 80
mogrify -format jpg -quality 80 *.png

ImageMagick is free, runs locally, handles any number of images, and has been the standard tool for this since 1990. It's not pretty, but it's fast, reliable, and doesn't upload anything.

Binary search compression: how to hit an exact file size

Most compressors ask "what quality do you want?" which is the wrong question. What you actually want is "make this image under 200KB while looking as good as possible." The right question is "what's the target file size?"

Binary search compression solves this. It works like a number guessing game:

1. Set low = 0.01 (minimum quality, smallest file), high = 1.0 (maximum quality, biggest file)
2. Try the midpoint quality. Is the result under the target size?
3. If yes: this quality works. Try higher to see if you can get better quality while still hitting the target. Set low = midpoint.
4. If no: too big. Need more compression. Set high = midpoint.
5. Repeat 6-8 times. The algorithm converges on the highest quality that still meets the size constraint.

This is more accurate than a fixed quality setting because different images compress differently. A simple graphic with large flat areas might hit 200KB at quality 95. A detailed photograph with lots of texture might need quality 65 to hit the same size. Binary search finds the right quality per image automatically.

Compress images in your browser — free, batch processing, no uploads →