Most advice on this question is either "it depends" or a number with no reasoning attached. Here are the numbers, and then the reasoning, so you can adjust them when your situation is not the common one.
The table
| Where it goes | Width | Target file size |
|---|---|---|
| Full-width hero | 1920 px | under 300 KB |
| Image inside an article | 1200 px | under 200 KB |
| Half-width / wrapped image | 800 px | under 120 KB |
| Card or list thumbnail | 400 px | under 50 KB |
| Avatar | 200 px | under 20 KB |
| Social share (Open Graph) | 1200 × 630 px | under 300 KB |
| Favicon | 32 × 32 and 180 × 180 | a few KB |
Treat the file sizes as targets, not limits. A detailed photograph earns more bytes than a flat graphic. If you are consistently 20% over, that is fine; if you are at four times the number, something is wrong.
Where those widths come from
The controlling number is how wide the image is displayed, not how wide the screen is. Most content sites cap the reading column somewhere between 650 and 800 px, because longer lines are harder to read. So an image inside an article is displayed at roughly 700 px however large the monitor is — which is why 1200 px is generous rather than stingy.
Heroes are the exception: they genuinely span the viewport, so they need to cover a common desktop width. 1920 px covers the overwhelming majority of screens. Going to 2560 px serves a small minority of very large monitors at a real cost to everyone else.
The retina question
High-density screens pack two or three physical pixels into each CSS pixel, so an image displayed at 700 px can use 1400 px of real detail. The naive conclusion is to double every number above. Do not.
Doubling the width quadruples the pixel count, and the visible benefit falls off fast. Two things make the trade-off much better than it looks:
- Compress harder on the larger version. A 2× image at 60% quality looks better than a 1× image at 90%, and is often smaller. The extra resolution hides the artifacts.
- Serve both and let the browser choose. The
srcsetattribute lets you offer a 1× and a 2× file; the browser downloads only the one it needs. This is the correct answer if your site can do it.
If you can only ship one file, going about 1.5× the display width and compressing a little harder is the pragmatic middle. For the article case that lands right on the 1200 px in the table.
The social preview is its own thing
The image that appears when someone shares your link is 1200 × 630 px, and unlike everything else on this page that is a specification rather than a suggestion. Facebook, LinkedIn and X all crop toward that ratio, and getting it wrong means your preview is letterboxed or has the heads cut off.
Two things that catch people: any text on it must be large, because it is often rendered at a third of its size in a feed; and the file has to be reachable at an absolute URL, since the scrapers do not resolve relative paths.
Hitting the targets
Resizing does most of the work and compression finishes it — in that order, because resizing is where the real savings are. Both happen in one pass in the image compressor: pick the max width from the table, leave quality at 75, and it reports the before and after in bytes so you can see whether you landed under target.
Batch matters more than it sounds. Twenty product photos at 3 MB each is 60 MB of page weight that should be about 3 MB. Doing them one at a time is how the job gets abandoned halfway.
What actually breaks when you get this wrong
Google's Core Web Vitals include Largest Contentful Paint, which measures how long the biggest visible element takes to appear. On most pages that element is an image, so an oversized hero is measured directly as a slow page — and Core Web Vitals feed into ranking.
There is also a plainer cost. A visitor on a phone with a weak signal is paying for every byte, and they leave long before your 6 MB hero finishes arriving. You never see them in analytics as a bounce, because the page never loaded enough to register.
One thing worth doing beyond size
Add width and height attributes to your <img> tags, matching the real dimensions. The browser then reserves the right amount of space before the image arrives, instead of reflowing the page when it lands. That reflow is Cumulative Layout Shift, the other Core Web Vital, and it is the thing that makes you tap the wrong button because the page jumped. It costs two attributes and fixes the problem entirely.
The quickest way through this is to open the image compressor, drop in everything at once, set the max width from the table above and leave quality at 75. It processes the whole batch and shows you the total saved, so you can tell at a glance whether you are under target. Nothing is uploaded — the resizing happens in your browser.
If your files are still heavy after resizing, the format is usually the culprit — a photograph sitting in a PNG will stay large no matter what width you give it. PNG vs JPG vs WebP covers which one belongs where, and why screenshots behave nothing like photos.
Frequently asked questions
What is the best image size for a website?
1920px wide for a full-width hero, 1200px for an image inside an article, 800px for a wrapped or half-width image, and 400px for thumbnails. The number that matters is the display width, not the screen width.
How big should a web image file be in KB?
Under 200 KB for an in-article image, under 300 KB for a hero, and under 50 KB for a thumbnail. These are targets rather than limits — a detailed photograph justifies more than a flat graphic.
Should I double image sizes for retina screens?
Not blindly. Doubling the width quadruples the pixels. Either serve both sizes with srcset and let the browser pick, or go about 1.5x the display width and compress a little harder — extra resolution hides compression artifacts well.
What size should a social share image be?
1200 x 630 pixels. Unlike the other numbers here this is a specification, not a suggestion — Facebook, LinkedIn and X all crop toward that ratio. Keep any text large, since it is often displayed at a third of its size.
Why do I need width and height on img tags?
So the browser can reserve the right space before the image loads, instead of reflowing the page when it arrives. That reflow is Cumulative Layout Shift, a Core Web Vital, and it is what makes you tap the wrong thing because the page jumped.
Last updated September 19, 2026