Compressing Images Without Wrecking Quality: A Practical Guide
By ABD Web Tools Editorial · 2026-01-26 · 8 min read
Images are usually the heaviest thing on a web page and the easiest thing to fix. A typical marketing page ships two to four megabytes of imagery that could be six hundred kilobytes with no visible difference on any screen. The trick is knowing which format suits which kind of picture, and where the quality curve stops being worth the bytes.
The three formats worth using
JPEG remains the safe default for photographs: universally supported, well understood, and perfectly adequate at sensible quality settings. WebP typically saves 25–35% over JPEG at matched visual quality and supports transparency, making it the best general-purpose choice today. AVIF compresses harder still, particularly on smooth gradients and large flat areas, at the cost of slower encoding.
PNG is for screenshots, logos and anything with sharp edges or text. Using PNG for a photograph is the single most common cause of a five-megabyte hero image.
Where the quality slider should sit
For photographs, quality 75–80 is the sweet spot in JPEG and WebP. Below 65 you start to see blocking in skies and skin tones; above 85 the file grows quickly while the visible improvement approaches zero.
For graphics with text, do not use lossy compression at all — the text edges fringe. Use PNG, or SVG if the source is vector.
Advertisement
Resize before you compress
Compression cannot rescue an image that is four times larger than its display size. If a card thumbnail renders at 400 pixels wide, export it at 800 pixels for high-density screens and stop there. Resizing usually saves more bytes than any codec choice.
- Hero images: 1600–1920 px wide is plenty for full-bleed layouts.
- Content images: 1200 px wide covers almost every article layout.
- Thumbnails: twice the rendered size, never more.
Strip metadata you do not need
Camera EXIF blocks, colour profiles and editing histories can add tens of kilobytes per image and sometimes include location data you did not intend to publish. Most compressors strip this by default; verify that yours does.
Serving strategy matters as much as file size
Set width and height attributes so the browser reserves space and the layout does not jump. Lazy-load everything below the fold. Serve multiple sizes through the srcset attribute so a phone never downloads a desktop asset. These three changes often improve perceived speed more than another 10% of compression.
A repeatable workflow
Resize to the largest size the layout will ever display, convert to WebP at quality 78, compare against the original at 100% zoom on the busiest region of the image, and only then decide whether AVIF is worth the extra encode time. For most sites the answer is: convert the top ten heaviest pages and stop.
Frequently asked questions
Is AVIF ready for production?
Browser support is broad now, but always provide a JPEG or WebP fallback through the picture element for older clients and for tools that fetch images programmatically.
Does compressing images help SEO?
Indirectly and reliably. Faster pages improve Core Web Vitals and reduce abandonment, both of which correlate with better search performance.
Should I compress in the browser or on a server?
Browser-based compression keeps your files private and is fast enough for individual images. Server pipelines make sense once you handle thousands per day.
Why does my compressed file get bigger?
Because the source was already compressed. Re-encoding an optimised JPEG at a higher quality setting adds bytes and removes detail — always compare against the original.
Advertisement
