Image Compression for the Web: What Sets the File Size

Compress Image shrinks a file by encoding pixels more efficiently. It cannot recover detail you already threw away, and it will not fix a photo that is still thousands of pixels wider than the slot on the page. Resize to the display size first, pick JPEG or WebP for photos and PNG when you need transparency, compress once, and check skies, faces, and text at 100% zoom before deploy.

A landing page can look crisp on a 27-inch monitor and still leave mobile users on 4G staring at a three-second blank gap. The same photos can show faint horizontal stripes in the sky that nobody noticed on desktop. Pixel count was only part of that failure. The files were compressed without a workflow that matched display size, format, and quality to where people actually view them.

Web image compression is the step that makes a right-sized file small enough to load quickly without looking broken.

What is image compression for the web?

Image compression reduces the bytes needed to store and transfer a picture. Lossy compression (JPEG, WebP lossy) removes data the encoder guesses viewers will not notice. Lossless compression (PNG, WebP lossless) rearranges data without dropping pixels. Compression works on whatever pixel grid you give it, so an oversized source stays oversized in memory even when the file shrinks only modestly on disk.

Why web image compression matters

Every image on a page competes with scripts, fonts, and the HTML document for bandwidth and decode time. Unoptimized photos are a common reason pages feel slow on mobile networks, and a common reason Largest Contentful Paint scores slip below Google's "good" threshold.

A careful pass keeps the picture acceptable while improving load time, Core Web Vitals scores, and bandwidth costs on high-traffic sites. A 2 MB hero on a page with ten inline images can push total image weight past 5 MB, enough to fail a performance budget even on a modern connection.

What sets the file size

Four things decide the size of a raster image, before any web-performance budget enters the picture.

Pixel dimensions come first. Double the width and the height and you have about four times the pixels. A 4000 by 3000 photo holds far more data than a 2000 by 1500 one. Resizing is usually the first cut.

Format is next. JPEG throws away detail that is hard to see in a photo. PNG keeps every pixel, which suits logos and screenshots and makes photographs heavy. WebP is often smaller than JPEG at a similar look. This site converts among PNG, JPG, and WebP. It does not convert HEIC.

The quality setting matters on the same photo. A high JPEG quality and a moderate one can differ by a large factor. Check the image at the size it will actually be shown.

What is in the picture matters too. A flat sky compresses more easily than a detailed forest. Two photos with the same dimensions and the same setting can still land at different sizes. The ranges below illustrate that spread. They are not a promise for your file.

| Format | Typical range for one 4000 by 3000 photo | Notes | | --- | --- | --- | | Uncompressed | About 36 MB | Pixel data with no compression | | PNG | About 10 to 18 MB | Lossless, and large for photos | | JPEG, high quality | About 5 to 8 MB | Large, little visible loss | | JPEG, moderate quality | About 2 to 4 MB | A common web starting point | | WebP, moderate quality | Often smaller than the JPEG | Compare on your own photo |

A screenshot stays smaller because it is fewer pixels and a lot of flat color. A phone photo is the opposite. Metadata such as camera settings and GPS is usually only kilobytes. Strip it for privacy, not because it will turn a multi-megabyte photo into a small one.

Compression vs. resizing

These work together and solve different problems.

| Step | What it does | Typical savings | |------|--------------|-----------------| | Resizing | Fewer pixels (e.g. 4000 by 3000 down to 1200 by 800) | Often 60 to 80% on camera files | | Compression | Smaller file per pixel (JPEG quality, WebP encoding) | 20 to 50% on already-sized files |

A 4000 px wide hero displayed at 1200 px should be resized to roughly 1200 to 1600 px width, then compressed. Resizing alone often saves more than aggressive compression on an oversized source. Use Resize Image before Compress Image when sources are camera-sized. The resize images for web guide covers display targets and retina math.

How compression works by format

Format choice changes how much a quality slider helps.

| Format | Best for | Compression type | Tradeoff | |--------|----------|------------------|----------| | JPEG | Photos, gradients | Lossy | Banding in skies at low quality | | WebP | Modern web photos | Lossy or lossless | Smaller than JPEG at equal visual quality | | PNG | Screenshots, UI, transparency | Lossless | Large files on photographs |

If you are serving JPEG today, test WebP Converter on the key assets and compare the look yourself. For the transparency choice, see PNG versus JPG.

When to compress images for the web

• Blog posts, product pages, and marketing landers before CMS upload
• Hero banners and Open Graph images before social scheduling
• Thumbnail grids where dozens of small files add up
• Email newsletters with inline images (many clients cap total message size)
• Migrating a content library from full-resolution camera uploads

When not to rely on compression alone

• Medical or technical imagery where fine detail is legally or clinically relevant
• Brand assets with strict color approval, because compression can shift tones slightly
• Images with embedded text, which need a lighter pass or PNG/WebP lossless regions
• Already-tiny icons, where SVG often beats raster compression for logos and UI marks
• A source that is already heavily compressed, because a second save stacks artifacts (see limitations below)

Step-by-step compression workflow

1. Audit display size. Check CSS max-width and the rendered dimensions in devtools.
2. Resize to the display size. Add modest headroom (1.5x) for retina screens. Skip 3x unless you need it.
3. Pick a format. Photos go to JPEG or WebP. UI with sharp edges or transparency stays PNG.
4. Compress toward a target. Aim for under 200 KB on large heroes and under 100 KB on thumbnails when possible.
5. Do a visual check. Zoom to 100% and look at faces, text overlays, and fine patterns.
6. Deploy with responsive markup. srcset and sizes keep mobile from downloading the desktop asset.

Quality settings: practical starting points

There is no universal number, because content varies. Starting points for JPEG and WebP quality sliders:

• Product thumbnails: 75 to 85
• Blog inline images: 80 to 88
• Full-width heroes: 82 to 90 (higher if text sits on the image)
• Background textures: 60 to 75 (soft detail hides artifacts)

Lower quality on a tiny thumbnail is rarely noticeable. Text on an image needs higher quality, or a PNG/WebP lossless region.

Real-world example: product page cleanup

A Shopify store had 2400 by 1600 product JPEGs exported at quality 95 from Lightroom, averaging 890 KB each across 40 SKUs. The fix:

1. Resize to 1200 px width in Resize Image. Files dropped to about 320 KB at the same quality.
2. Compress at quality 82 in Compress Image. The final average was 95 KB.
3. Convert heroes to WebP via WebP Converter. They landed at 68 KB, with no visible change on the fabric weave at a normal viewing distance.

Total image weight on the category page fell from 36 MB to 3.8 MB. LCP improved from 4.2 s to 1.8 s on simulated mobile. The owner checked one zoomed fabric texture and accepted it. That single check avoided a support ticket about "blurry products."

Export habits

• Export from design tools at 2x display width, not full canvas size
• Name masters filename-master.jpg before any web pass
• Batch-compress uploads in CI, and still check heroes and campaign assets by hand
• Pair compression with lazy loading for below-fold images, and compress heroes first for LCP
• WordPress and headless CMSs often cap upload size (2 to 10 MB). Resize and compress before upload

Common mistakes

Compressing before you resize encodes pixels you will throw away. Resize first.

Saving over the only copy stacks artifacts on the second lossy pass. Archive the master.

One quality setting does not fit every asset. Thumbnails and heroes are different jobs.

A preview at 50% zoom hides damage. Check at 100% on desktop, and at arm's length on a phone.

Lossless compression of a 6 MB PNG photograph barely helps. Convert to WebP or JPEG first.

Troubleshooting

| Problem | Likely cause | Fix | |---------|--------------|-----| | Horizontal banding in skies | Quality too low on gradients | Raise quality 5 to 10 points or switch to WebP | | Fuzzy text on image overlay | Lossy compression on type | Higher quality, or PNG/WebP lossless for that region | | File still huge after compression | Source dimensions too large | Resize before compressing | | Colors look washed out | Double compression or wrong export | Compress once from the master; check the color profile | | Mobile still downloads desktop file | No srcset | Add responsive variants at 400w, 800w, 1200w |

Privacy and browser processing

Compression tools that upload to a server see your pixels. For client work, unreleased products, or NDAs, prefer browser-based processing. Vertex Solutions image tools run locally, so the file does not leave the device during compression or conversion. Read more in how browser file processing protects privacy.

Limitations

Lossy compression is one-way. You cannot recover quality later, so keep a master.

A soft upload stays soft. Compression only makes it smaller.

Re-compression stacks artifacts. Do not compress an already-compressed JPEG twice.

SVG and video need different workflows. This guide covers raster images (JPEG, PNG, WebP).

Automated tools miss art direction. A CI plugin will not notice that one hero has critical text in a gradient zone. Manual QA on key assets still matters.

When compression alone is not enough, resize further, switch format via PNG to JPG, crop dead space in Crop Image, or use responsive srcset so mobile never downloads desktop bytes.

Related articles

• Compress an image, the tool
• Resize images for the web, display size before compression
• PNG vs JPG Guide, format trade-offs
• Core Web Vitals and Images, LCP and performance budgets

Conclusion

Resize to the display size, pick the format, compress once at a quality you checked, and zoom the ugly parts (skies, skin, shadows, small text) before you ship. A right-sized file that was compressed once is what keeps the page fast for someone on a phone in bright sunlight.