Image Compression and File-Size Budgets: How to Pick Pixels, Format and Quality

Most advice about image compression starts with the quality slider. That's the wrong end. The biggest savings come from deciding how many pixels you actually need, then picking a format, and only then nudging quality. This guide works through that order with real arithmetic, so you can set a file-size budget for a page and hit it on purpose instead of by trial and error.

Start with the raw numbers

A photo from a typical 12-megapixel phone camera is 4032 × 3024 pixels. That's 12,192,768 pixels. Each pixel needs three bytes for red, green and blue once it's decoded, so the image takes up 36.6 MB in memory (about 34.9 MiB) no matter what format it was saved in. The JPEG on disk might be 2 to 4 MB, which means the camera's encoder has already thrown away roughly nine-tenths of the raw data.

Now look at where that photo ends up. A blog content column is often around 700 to 800 CSS pixels wide. On a phone with a 2× screen, 800 CSS pixels needs 1,600 device pixels to look sharp. So the useful version of that photo is about 1600 × 1200. That's 1,920,000 pixels, or 5.76 MB decoded. You've cut the pixel count by 84% before touching the quality slider at all.

This is why resizing comes first. Compression works per pixel. A quality setting that saves 70% on a 12 MP image still leaves you shipping six times more pixels than the screen can show.

Think in bits per pixel

A handy way to predict file size is bits per pixel (bpp). Take the file size in bits and divide by the pixel count. Because this is just arithmetic, you can use it to sanity-check any output. Here's what different bpp values would mean for the 1600 × 1200 image:

The bpp you actually get depends on the content. A photo of a sky with a smooth gradient compresses very differently from a photo of gravel or foliage. Fine, random texture is expensive to encode because there's nothing for the encoder to predict. Flat areas are cheap. That's why two photos at the same dimensions and the same quality setting can differ in size by a factor of two or three.

Set a budget from load time, not from a round number

A file-size budget is useful only if it's tied to something real. Load time on a slow connection is a good anchor. Lighthouse's default mobile throttling simulates a link of about 1.6 Mbps (1,638.4 kbps). At that speed:

If your hero image is the Largest Contentful Paint element, and Google's "good" LCP threshold is 2.5 seconds, a 1 MB hero blows the budget on that connection before the browser has done anything else. A 200 KB hero leaves room for the HTML, CSS and fonts. So a reasonable budget for a full-width hero is somewhere around 150 to 250 KB, and in-content images can usually sit lower, around 60 to 150 KB each.

Add up the page too. Ten in-content images at 150 KB each is 1.5 MB, which is 7.3 seconds of transfer at 1.6 Mbps. Lazy loading helps because images below the fold don't compete with the first screen, but the bytes still cost mobile data. If a page has many images, lowering each one by 50 KB matters more than squeezing the hero.

Pick the format by content type

• Use JPEG or WebP for photos. Both are lossy and both use transforms that suit natural images. WebP typically comes out smaller at similar visual quality, and every current major browser supports it.
• Use PNG or lossless WebP for screenshots, interface captures, diagrams and logos with flat colour. JPEG smears sharp edges into blocky "ringing" artefacts around text, and those look worse the more you compress.
• Anything that needs transparency should be PNG or WebP. JPEG has no alpha channel, so transparent areas get filled with a solid colour.
• Icons and simple illustrations are best as SVG, if you have the vector source. A 2 KB SVG beats any bitmap and stays sharp at every size.

A common mistake is saving a screenshot as JPEG to make it smaller. It usually works on the file-size number but the text gets fuzzy halos. The reverse mistake is worse: saving a photo as PNG. A lossless PNG of a 1600 × 1200 photo will often be several megabytes, because lossless compression can't discard the sensor noise that's in every photo.

What the quality slider actually does

For JPEG and lossy WebP, the quality number controls how coarsely the encoder rounds frequency data. Lower quality means more rounding, fewer distinct values to store, and smaller files. The relationship isn't linear. Going from 100 to 90 often cuts a large chunk of the size with no visible change, because quality 100 spends bits preserving noise nobody can see. Going from 60 to 50 saves much less and starts showing blockiness in skies and skin.

A practical routine: export at 80, look at the result at 100% zoom on the parts that break first (smooth gradients, faces, text overlays), then try 70. If you can't see a difference at 70, keep it. If you can, go back to 80. Don't judge at a zoomed-out thumbnail size, where almost any setting looks fine.

Using the Toolminex Image Compressor for this

The Image Compressor runs in your browser. It draws your image onto an HTML canvas and re-encodes it with the browser's built-in encoder using the format and quality you pick (10 to 100, default 80). Nothing is uploaded. It then reports the new size so you can compare against your budget.

1. Resize first with the Image Resizer. The compressor keeps the original pixel dimensions, so a 4032 × 3024 photo stays 4032 × 3024.
2. Open the compressor, choose JPEG or WebP for photos, and start at 80.
3. Compare the reported size with your budget. Use the bpp formula above to work out how far you are from it.
4. Step quality down in 10-point jumps and check the preview at full size each time. Stop at the last setting you can't tell apart from the one above it.

Limitations to know about

• PNG output is lossless here. The canvas PNG encoder has no quality setting, so choosing PNG ignores the slider. A PNG re-encoded this way can even come out larger than the original if the source had been through a better optimiser.
• JPEG output flattens transparency to white. If you compress a transparent PNG to JPEG, the see-through parts become solid white.
• Metadata is dropped. Canvas re-encoding doesn't carry over EXIF data, so camera details, capture date and GPS location won't be in the output. That's good for privacy, but bad if you rely on that data.
• Encoders differ between browsers. Chrome, Firefox and Safari ship different JPEG and WebP encoders, so the same image at the same quality can produce slightly different sizes depending on where you run it.
• It handles one image at a time. There's no batch mode, so a folder of 200 product photos is better handled by a command-line tool or a build step.
• The tool doesn't aim for a specific file size or visual-quality score automatically. You choose the quality and judge the result yourself.

A checklist you can reuse

1. Measure the largest width the image will ever display at, in CSS pixels, and multiply by 2 for high-density screens.
2. Resize to that width. Don't upscale small images; it adds bytes without adding detail.
3. Choose the format by content: JPEG or WebP for photos, PNG or lossless WebP for flat graphics, SVG for vectors.
4. Set a budget per image from load time. Around 200 KB for a hero and 60 to 150 KB for in-content images is a sensible starting point.
5. Compress, check at 100% zoom, and record the setting that worked so the next image takes seconds, not minutes.

None of these numbers are fixed rules. A photography portfolio might rightly spend 600 KB on a single image because the image is the product. A news article with twenty inline photos needs to be stingier. What matters is that the budget is a choice you made with the arithmetic in front of you.