How to Compress Images for Website Speed (2026 Guide)

Why images decide how fast your page feels

Core Web Vitals measure three things: how fast the main content appears (LCP, good at 2.5 seconds or less), how stable the layout is while loading (CLS, good at 0.1 or less) and how quickly the page reacts to input (INP, good at 200 ms or less). Images touch two of the three. A 3 MB hero photo can take several seconds to arrive on a mobile connection, and because it is usually the largest visible element, that delay becomes your LCP. Images without reserved dimensions push text around as they load, which raises CLS.

The fix has four parts, in this order: resize the image to the size it is displayed at, pick the right format, compress it, and serve it with the right HTML attributes. Skipping the first step is the most common mistake — no amount of compression makes a 6000-pixel photo displayed at 800 pixels efficient.

Step 1: Resize to the size you actually display

Phone cameras produce photos 4000–6000 pixels wide. A blog content column is typically 700–900 CSS pixels wide, and a full-width hero rarely needs more than 1920. To stay sharp on high-density ("retina") screens, export at up to twice the displayed CSS width, but no more.

Practical targets that work for most sites:

If you use WordPress, Shopify or a similar CMS, it generates smaller versions automatically — but it still stores and often serves your original, so upload an image that is already a sensible size.

Step 2: Choose the right format

JPEG is the safe default for photographs: universally supported, small, and good at smooth gradients. PNG is for screenshots, logos, diagrams and anything with sharp edges, text or transparency — never use it for photos, where it can be five to ten times larger than a JPEG. WebP is supported by every current browser and is typically 25–35% smaller than JPEG at similar visual quality, and it also supports transparency. AVIF compresses even further but encodes slowly and isn't supported by every tool yet — see our AVIF vs WebP comparison for when it is worth it. SVG is best for logos and icons drawn as vectors: it stays sharp at any size and is often just a few kilobytes.

A simple rule: photos → JPEG or WebP; graphics with few colours or transparency → PNG or WebP; logos and icons → SVG.

Step 3: Compress — how much is enough?

For JPEG and WebP, a quality setting around 75–85% is usually indistinguishable from the original on screen while cutting file size dramatically; going below 60% starts to show blocky artefacts around edges and text. For PNG, reducing the colour palette (quantisation) shrinks screenshots and graphics a lot, but can cause banding in gradients.

Useful rules of thumb — not hard limits: aim for under ~200 KB for a hero image and under ~100 KB for a typical content image. If a photo is still much larger after resizing and compressing at 80%, it is probably PNG when it should be JPEG, or still far wider than it is displayed.

Also strip metadata. Camera photos carry EXIF data — camera model, date and often GPS location — that adds bytes and can reveal where a photo was taken. Browsers don't need it.

Step 4: Serve images the right way in HTML

Even perfectly compressed images can hurt performance if the page loads them badly:

• Always set width and height (or a CSS aspect-ratio) so the browser reserves space and the layout doesn't jump — this is the main image fix for CLS.
• Use srcset and sizes to offer several widths of the same image, so phones download the small version and large screens the big one.
• Lazy-load images below the fold with loading="lazy", but never lazy-load the LCP image — the hero should load immediately, ideally with fetchpriority="high".
• Cache and serve from a CDN so repeat visitors and distant users get images quickly. Long Cache-Control lifetimes are safe for files whose names change when their content changes.

Most modern CMSs and frameworks handle srcset and lazy-loading for you; check that your hero image is excluded from lazy-loading, because many themes lazy-load everything by default.

How to compress website images privately with MiniFiles

MiniFiles compresses images inside your browser, so unpublished product shots, client work or photos of people are never uploaded to a third-party server. A practical workflow:

1. Open the image compressor and drop in a batch of JPG, PNG, WebP or GIF files.
2. Adjust the Quality slider (80% by default) — it is free for everyone.
3. Download the results. EXIF data, including GPS location, is removed from JPEG and WebP by default.

Photos larger than 4096 pixels on either side are scaled down to fit automatically. Choosing an exact maximum width (for example 1600 px for content images) and converting to WebP are Pro features; on the free plan you can resize with your operating system's photo app first. For format-specific details see Compress JPEG and Compress PNG.

Check the result: measuring image performance

Run your page through PageSpeed Insights or the Lighthouse panel in Chrome DevTools. Look at the LCP element it reports — if it is an image, that image is your top priority. Lighthouse flags oversized, badly encoded or legacy-format images (in recent versions these checks are grouped under Improve image delivery) and estimates how many kilobytes you would save. Field data from real visitors (shown at the top of PageSpeed Insights once your site has enough traffic) is what Google actually uses for Core Web Vitals, so re-check it a few weeks after optimising.

Quick checklist

• Resize every image to at most 2× its displayed width.
• Photos in JPEG or WebP, graphics in PNG or WebP, logos in SVG.
• Compress JPEG/WebP at 75–85% quality.
• Strip EXIF metadata.
• Set width and height on every image.
• Use srcset/sizes for responsive images.
• Lazy-load below-the-fold images, never the hero.
• Measure with PageSpeed Insights before and after.