What file size should a website image actually be?

As a rule of thumb: hero/banner images (full-width, above the fold) under 200KB, in-content or blog photos under 100KB, and thumbnails or product grid images under 50KB. These aren't hard limits — they're targets that keep a typical page's total image weight in a range (roughly 1-2MB total) that loads quickly on an average mobile connection, which matters directly for Google's Core Web Vitals and search ranking.

Does image size really affect SEO?

Yes, indirectly but measurably. Google's Core Web Vitals include Largest Contentful Paint (LCP) — how long it takes the biggest visible element, often a hero image, to render — as a ranking signal. An unoptimized 3-5MB hero image can single-handedly push a page's LCP into the 'poor' range on mobile connections, which can affect ranking independent of the page's actual content quality.

Should I resize the image, compress it, or both?

Both, and in that order. Resize to the actual maximum display width first (a blog post body is rarely wider than 800-1200px even on a large monitor, because of max-width CSS on the content column), then compress. Serving a 4000px-wide camera photo compressed to a small file size wastes bits encoding detail nobody's screen will show, when the same file size spent on a correctly-sized 1000px image would look sharper.

When should I use WebP instead of JPEG for web images?

Almost always for photos: WebP typically produces 25-35% smaller files than JPEG at equivalent visual quality, and it's supported by every browser released since 2020. Use JPEG only if you specifically need compatibility with very old software that processes the site's images outside a browser (some legacy CMS plugins, certain print-from-web workflows). See converting PNG to WebP for the same trade-off from PNG.

What about lazy loading — does that mean I don't need to compress images?

Lazy loading (native loading="lazy" or a JS library) defers off-screen images until the user scrolls near them, which helps initial page load but doesn't reduce the eventual download size — every image still gets downloaded at full weight once it's in view. It's a complement to compression, not a substitute for it, and it does nothing for your LCP image, which by definition is visible immediately and shouldn't be lazy-loaded at all.

Optimize an Image for Your Website

Compress image to target size

Try this tool now

Drop a file here, or choose one

Resize to your site’s actual display width, then compress with the tool above — the target sizes and reasoning below will help you pick the right numbers for each image’s role on the page.

Target sizes by role

Hero / banner images (full-width, visible without scrolling): under 200KB. This is your Largest Contentful Paint element on most pages, so its load time directly affects a Core Web Vitals metric Google uses in ranking.
In-content / blog photos: under 100KB. These load as the user scrolls, so they’re less critical than the hero image, but a page with 10+ of these at 500KB each adds up to a genuinely slow page.
Thumbnails / product grid images: under 50KB each. Small display size means there’s no visual cost to aggressive compression, and grids often show a dozen or more at once.

These are targets, not hard rules — a photography portfolio site legitimately needs larger, higher-fidelity images than a text-heavy blog. The point is to be deliberate about the trade-off rather than uploading whatever your camera or phone produced by default.

Why this affects search ranking, not just user experience

Google’s Core Web Vitals include Largest Contentful Paint (LCP): the time until the largest visible element — usually a hero image or headline — finishes rendering. This is a measured ranking factor, not a vague “user experience” hand-wave. An unoptimized multi-megabyte hero image can push mobile LCP well past Google’s “good” threshold (2.5 seconds) on an average connection, and that’s enough to visibly hurt ranking independent of how good the page’s content is.

Resize before you compress, not instead of

Compression and resizing solve different problems. Compression reduces the bits used to encode each pixel; resizing reduces the number of pixels. If your content column is 900px wide but you’re serving a 4000px-wide photo (just compressed down in file size), you’re spending bits encoding detail no browser will ever display at that width — the same file size budget applied to a correctly-sized 900px image looks noticeably sharper. Always resize to the real maximum display width first.

WebP vs JPEG for web use

WebP typically beats JPEG by 25-35% at equivalent visual quality for photographic content, with universal support in modern browsers. If your CMS or platform supports it, converting compressed JPEGs to WebP is close to a free size reduction. The savings are often even larger for graphics and screenshots converted from PNG — see the related solution below.

Lazy loading doesn’t replace compression

Deferring off-screen images with loading="lazy" improves initial page load by not downloading everything at once, but every image still downloads at full size once it scrolls into view — and your hero/LCP image is visible immediately, so it shouldn’t be lazy-loaded at all. Compression reduces the actual bytes transferred; lazy loading just changes when they’re transferred.

Frequently asked questions

What file size should a website image actually be?: As a rule of thumb: hero/banner images (full-width, above the fold) under 200KB, in-content or blog photos under 100KB, and thumbnails or product grid images under 50KB. These aren't hard limits — they're targets that keep a typical page's total image weight in a range (roughly 1-2MB total) that loads quickly on an average mobile connection, which matters directly for Google's Core Web Vitals and search ranking.
Does image size really affect SEO?: Yes, indirectly but measurably. Google's Core Web Vitals include Largest Contentful Paint (LCP) — how long it takes the biggest visible element, often a hero image, to render — as a ranking signal. An unoptimized 3-5MB hero image can single-handedly push a page's LCP into the 'poor' range on mobile connections, which can affect ranking independent of the page's actual content quality.
Should I resize the image, compress it, or both?: Both, and in that order. Resize to the actual maximum display width first (a blog post body is rarely wider than 800-1200px even on a large monitor, because of max-width CSS on the content column), then compress. Serving a 4000px-wide camera photo compressed to a small file size wastes bits encoding detail nobody's screen will show, when the same file size spent on a correctly-sized 1000px image would look sharper.
When should I use WebP instead of JPEG for web images?: Almost always for photos: WebP typically produces 25-35% smaller files than JPEG at equivalent visual quality, and it's supported by every browser released since 2020. Use JPEG only if you specifically need compatibility with very old software that processes the site's images outside a browser (some legacy CMS plugins, certain print-from-web workflows). See converting PNG to WebP for the same trade-off from PNG.
What about lazy loading — does that mean I don't need to compress images?: Lazy loading (native loading="lazy" or a JS library) defers off-screen images until the user scrolls near them, which helps initial page load but doesn't reduce the eventual download size — every image still gets downloaded at full weight once it's in view. It's a complement to compression, not a substitute for it, and it does nothing for your LCP image, which by definition is visible immediately and shouldn't be lazy-loaded at all.