On a typical web page, images account for somewhere between half and three quarters of the total bytes downloaded. Nothing else you can do to a page — not minifying CSS, not deferring scripts, not switching frameworks — comes close to the win available from handling images properly.
The good news is that most sites are leaving enormous savings on the table through three specific mistakes, and all three are easy to fix.
Resize before you compress
This is the one people skip, and it is worth more than everything else combined.
A photo straight from a phone is routinely 4000 pixels wide. If you display it in a 600-pixel-wide column, the browser downloads all 4000 pixels and throws away 85% of them on every single page load. Compressing that 4000-pixel image helps; resizing it to 1200 pixels first helps far more, because file size scales roughly with pixel count, not width.
Halving both dimensions quarters the pixel count. Going from 4000px to 1200px — a factor of 3.3 in each direction — cuts the pixels by about 91% before you have compressed anything at all.
What size should you actually export?
Take the widest the image will ever be displayed, and double it for high-density screens. That is your export width.
- In-article images — usually displayed around 700px, so export at 1400px.
- Full-width hero images — up to 1920px display, so 2560px is a reasonable cap. Going beyond that has diminishing returns.
- Thumbnails and avatars — displayed at 100–200px, so export at 200–400px. These are frequently shipped at full resolution and are the easiest win on any site.
- Open Graph share images — exactly 1200 × 630.
If you serve genuinely responsive images with srcset, export two or three widths and let the browser pick. If you serve one file, size it for your largest realistic display and accept that small screens download a little more than they need.
Pick the right format
Format choice routinely matters more than the quality slider.
| Format | Use for | Avoid for |
|---|---|---|
| WebP | Almost everything. 25–35% smaller than JPEG at equal quality, supports transparency. | Nothing, in practice — support is universal in current browsers. |
| JPEG | Photographs, when you need maximum compatibility. | Logos, screenshots, text, anything with sharp edges or transparency. |
| PNG | Logos, icons, screenshots, diagrams, transparency. | Photographs — a photo as PNG can be five times larger than the same image as WebP. |
| SVG | Logos, icons, simple illustrations. Infinitely scalable, usually tiny. | Photographs. SVG is vector, not raster. |
The most common format mistake is a photographic image saved as PNG — often because it was exported from a design tool with PNG as the default. Converting those to WebP typically cuts 70–85% with no visible difference.
Choosing a quality setting
JPEG and WebP are lossy: they discard detail your eye is poor at noticing. The quality slider controls how aggressive that is.
- 90–100% — near-lossless. Use for print, photography portfolios, or images that will be edited again.
- 75–85% — the sweet spot for the web. Large savings, no artefacts visible on most photographs. 80% is a sensible default.
- 50–70% — noticeable softening on detailed images, acceptable for thumbnails and background images.
- Below 50% — visible blocking and colour banding. Rarely worth it.
Images with sharp edges behave differently. Logos, screenshots, diagrams and anything containing text show compression artefacts far earlier than photographs — the fringing around high-contrast edges is very visible. Keep those above 85%, or use PNG and skip the question.
Compress once, from the original
Lossy compression is not reversible. Each pass discards real detail, and the losses accumulate. Compressing an already-compressed image saves very little and degrades it noticeably — the easily-discarded information is already gone, so the encoder starts eating into detail that matters.
Always work from the highest-quality original you have. Keep those originals somewhere; the compressed version is a derivative, not an archive.
The same applies to format conversions. Converting JPEG → PNG does not restore anything; it just stores the already-degraded image losslessly, at a much larger file size.
What compression does to your metadata
Re-encoding an image through a browser's Canvas API — which is how our Image Compressor works — drops all EXIF metadata as a side effect.
For images you are publishing, that is usually desirable. Phone photos embed GPS coordinates by default, and posting an unedited photo taken at home can publish your address to anyone who knows how to read the metadata. Compression strips it along with everything else.
If you need to check what is in a file before deciding, the Image Metadata Viewer reads it locally without uploading anything.
A practical workflow
- Start from the original. Never from a file that has already been compressed.
- Crop first if the composition needs it — no sense compressing pixels you are going to discard.
- Resize to twice the maximum display width.
- Convert to WebP unless you specifically need something else.
- Compress at 80%, then look at the result at full size before accepting it.
- Check the file size. For an in-article image, anything over about 200 KB deserves a second look.
Steps 2 to 5 are each one tool on this site, and all of them run in your browser — your images are never uploaded anywhere.
Why this matters beyond page speed
Google measures Largest Contentful Paint as a ranking signal, and on most content pages the largest contentful element is an image. A hero image that takes three seconds to arrive is a direct, measurable SEO problem, not just an aesthetic one.
There is also a straightforward cost argument. If you serve a million page views a month and shave 800 KB off each one, that is 800 GB of bandwidth per month you are no longer paying for — and 800 GB your visitors on metered mobile connections are no longer paying for either.
Frequently asked questions
Is WebP safe to use in production?
Yes. Every current browser supports it, including Safari since 2020. If you need to support genuinely ancient browsers, serve WebP with a JPEG fallback using the picture element.
Should I compress images if my CDN already does it?
Usually yes. Most CDN optimisation applies a generic quality setting and does not resize to your actual display dimensions. Resizing correctly before upload still wins.
How small should a web image be?
As a rough target: under 100 KB for in-article images, under 300 KB for a full-width hero, under 20 KB for thumbnails. If you are far above those, the usual cause is that the image was never resized.
Does compressing an image remove its EXIF data?
Yes, when the compression works by re-encoding through Canvas, as browser-based tools do. That includes GPS coordinates, which is generally a good thing for anything you publish.
Why does my logo look blurry after compression?
Lossy compression handles sharp edges badly. Logos, screenshots and text should be PNG or SVG, not JPEG or heavily-compressed WebP.
Everything on ToolYard runs in your browser. No uploads, no accounts, no limits.
Browse all tools →