How to compress images for websites, email and upload forms

Most “file too large” problems have the same fix: fewer pixels, then a sensible quality setting, in a format the destination accepts. Do those three things in that order and most photos shrink to a small fraction of their original size, with no difference anyone will notice on a screen. This guide explains why each step works, with numbers we measured rather than guessed.

Lossy and lossless compression, in plain terms

Lossless compression is like packing a suitcase more neatly. Everything you put in comes back out exactly the same, pixel for pixel. PNG works this way, and so does lossless WebP. It is great for screenshots, logos and diagrams, where large areas share one color and patterns repeat. It is much less effective on photos, because camera images are full of tiny, random variations that don’t repeat.

Lossy compression is more like a skilled summary. JPG, lossy WebP and AVIF split the picture into small blocks, describe each block as a mix of smooth gradients and finer detail, and then keep the fine detail only as precisely as you ask them to. Your eye is far more sensitive to overall brightness and shape than to fine texture or exact color, so a lot can go before anyone notices. What goes doesn’t come back, which is why you should always keep the original.

The practical rule: photos and anything camera-made are lossy territory; flat graphics, text and anything with sharp edges against solid color are lossless territory.

What the quality number actually means

The quality slider (1 to 100 in our compressor) looks like a percentage, but it isn’t a percentage of anything. Quality 75 does not keep 75% of the detail, and it doesn’t produce 75% of the file size. It is a dial that the encoder translates into how coarsely to round off detail in each block. Higher numbers mean finer rounding, more data kept and bigger files.

Google’s web.dev guidance on JPEG puts it bluntly: not every tool interprets a value of 75 the same way, and perceived quality depends on the image. The scales also differ between formats. In our image compressor, the Balanced preset is 75 for JPG and WebP but 50 for AVIF, because AVIF’s scale runs differently. Comparing “quality 75” across formats or apps is comparing labels, not results.

Two more things worth knowing:

• The curve is steep at the top. On our 1600 × 1200 test photo, MozJPEG at quality 75 produced 81.4 KB; at quality 88 it produced 176.0 KB, more than twice the size for a difference that is hard to see on screen.
• Size doesn’t always move smoothly. On the same photo, quality 79 came out at 97.4 KB and quality 80 at 115.8 KB. Encoders don’t respond to the dial in perfectly even steps, so one notch can make a surprising jump. That is one reason a target-size search tests real encodes rather than predicting.

Lighthouse, Google’s page-auditing tool, estimates savings for JPEG images by re-encoding them at a compression level of 85 and flags any image where that would save 4 KiB or more. That is a useful benchmark for web images, not a rule.

Resize first: pixels drive file size

Every pixel costs bytes, so the biggest lever is the number of pixels. Halve the width and height and you have a quarter of the pixels. Uncompressed, our test photo is 1600 × 1200 × 4 bytes (red, green, blue and alpha) = 7,680,000 bytes. Compression shrinks that enormously, but the compressed size still tracks the pixel count.

A typical 12-megapixel phone photo is 4032 × 3024 pixels. Resized to 1600 pixels wide with the aspect ratio locked, it becomes 1600 × 1200, because 4032 ÷ 1600 = 2.52 and 3024 ÷ 2.52 = 1200. That is 12,192,768 pixels down to 1,920,000, about 6.35 times fewer. A web page column or an email preview rarely needs more.

Here is what the same photo measured at three widths, all saved as JPG quality 75 with the same encoder:

Going from 1600 to 800 pixels wide cut the pixel count by 75% and the file by 75%, with no change to the quality setting. On this photo, file size followed the pixel count closely; on others it won’t track it exactly, but the direction never changes.

How big is big enough? Lighthouse’s “Properly size images” audit flags images whose rendered size is at least 4 KiB smaller than the file served, so match the width to the largest size the image will actually be displayed at, allowing about twice that for sharp high-density screens. The image resizer does this in a batch, with a “don’t enlarge” option so small images are left alone.

Hitting a target like 100 KB, 200 KB or 1 MB

Upload forms love hard limits: “maximum 200 KB”, “under 1 MB”. You could nudge a quality slider and re-save until it fits, which is exactly what a target-size search does for you, only faster and more methodically.

The compressor’s target mode runs a binary search over quality 30 to 95. It first tries 95; if that fits, done. Otherwise it tries the middle of the remaining range, keeps whichever half could still contain the answer, and repeats, using at most seven encodes. The result is the highest quality that fits, without trying all 66 settings.

We ran that same search, with the same encoder, on our 1600 × 1200 test photo:

For 200 KB the search settled on quality 89; for 100 KB, quality 79; for 50 KB, quality 60. All three fit without touching the dimensions.

The last row shows why some targets are unreachable. Even at quality 30, the full-size photo was 19.0 KB. When the quality floor still doesn’t fit, the compressor shrinks the image in a few estimated steps, here down to 400 × 300, a quarter of the width, and it still came out at 3.2 KB. At that point it stops and reports the smallest size it achieved instead of quietly producing mush. If you hit this, the target is too small for the picture: resize to smaller dimensions yourself, try a more efficient format, or ask whether the limit is really meant for photos.

Picking a format (briefly)

For photos, JPG is the universally accepted choice, while WebP and AVIF usually produce smaller files at similar visual quality. In our measurements, lossy WebP at quality 75 came out at 61.2 KB against 81.4 KB for JPG at the same setting. For graphics with flat color, text or transparency, a lossless format is usually both smaller and cleaner. Our full comparison, with a measured benchmark, is in JPG vs PNG vs WebP vs AVIF. To switch a batch over, use the WebP converter or set the output format inside the compressor.

One caution: an upload form that asks for “JPG or PNG” means it. WebP and AVIF are excellent on your own website but not every form or older app accepts them. If a picture is going to a form, save JPG.

Size limits for email attachments and web pages

Email

Google’s Gmail Help says the attachment limit for personal Gmail accounts is 25 MB; for work and school accounts, the Google Workspace administrator sets it. If attachments exceed the limit, Gmail removes them and adds a Google Drive link instead. Microsoft’s Outlook support page gives 20 MB for internet accounts such as Outlook.com and a default of 10 MB for Exchange business accounts, and notes that the limit covers the attachment and the email together.

Leave headroom. Email carries attachments as text using Base64, which, per the MIME standard (RFC 2045), turns every 3 bytes into 4 characters. So the message travels roughly a third larger than the files you attached. The recipient’s mail server may also have a lower limit than yours.

The easy win is resizing. Photos to be viewed on a screen almost never need full camera resolution. At the sizes measured above, twenty photos at 1600 pixels wide and quality 75 would come to about 1.6 MB, comfortably inside every limit mentioned here.

Web pages

On a website, image bytes are download time. Google’s web.dev guidance recommends trying several quality levels to find the best trade-off for each image, and serving modern formats where you can. Lighthouse flags images that are bigger than their displayed size and images that would shrink by 4 KiB or more when re-encoded.

Metadata: free savings and a privacy bonus

Photos carry EXIF metadata: the camera model, the date, exposure settings, often an embedded preview thumbnail and sometimes the GPS coordinates of where it was taken. Removing it saves a little space and stops you sharing your location by accident. The compressor removes all metadata by default, or can keep camera and date details while dropping location. If you only want metadata gone without re-compressing, the EXIF remover strips it while copying the image data byte for byte. The guide to removing location data from photos covers what else can be in there.

Worked example: one photo, three destinations

That’s the whole method: decide how many pixels the destination really needs, resize to that, then let the quality setting or a target size do the rest. Everything runs in your browser, so the photos themselves are never uploaded anywhere to be compressed.

Written and checked by the PixWrench team against the sources listed above. Spotted something out of date? Tell us and we’ll check it and note the fix in the changelog.