Most guides to image sizes hedge their answers because the right size genuinely depends on context. That is fair, but unhelpful when you are trying to ship a website on Tuesday. So here are the practical numbers first, then the reasoning behind each.
The quick reference
If you just need a number for right now:
- Hero or banner image: 1920 pixels wide, 200 to 400KB
- In-content image: 1280 pixels wide, 80 to 200KB
- Thumbnail: 400 to 600 pixels wide, 30 to 80KB
- Product photo (e-commerce): 1500 to 2000 pixels square, 150 to 300KB
- Open Graph share image: 1200 by 630 pixels, under 1MB
- Email body image: 600 pixels wide max, under 100KB
- Favicon: 32 by 32 pixels, plus a 180 by 180 PNG for the Apple touch icon
Stick within those and your site will load quickly on any reasonable device, never trigger a "properly size images" warning from PageSpeed, and look correct everywhere your URL gets shared.
The rest of this post explains why these numbers and where they bend.
Hero images
The image at the top of your page is almost always your Largest Contentful Paint element. Get this one wrong and Core Web Vitals takes the hit on every single visit, which costs you in search rankings.
1920 pixels is the sweet spot for the longest edge. It looks crisp on every desktop including most 4K monitors (those are usually viewed at scaled resolution, so 1920 is effectively a 2x asset). On a Retina laptop you would struggle to spot the difference between 1920 and 2560 in a real hero shot. Going higher doubles the file size for a quality gain nobody can see in normal use. Keep 4K originals for print.
For aspect ratio: 16:9 (1920 by 1080) works for most landscape heroes. 21:9 (1920 by 820) is good for slim banner styles. Square works for portfolios and personal sites. Pick one shape and stick to it across your site, mixing aspect ratios in similar layouts always looks wrong.
Save as WebP if your CMS supports it. JPG quality 80 is the right fallback. Either way, keep the file size at or below 400KB. You can hit that target on a normal photo without anyone noticing the compression.
In-content images
These are the photos that live inside articles, blog posts, product descriptions. They sit at the width of your content column, which on most modern sites is between 700 and 900 pixels.
Serve them at 1280 pixels on the long edge. That gives crisp rendering on Retina displays where the browser is effectively rendering at 2x, and keeps the file size well under 200KB if you compress at a normal quality setting.
There is almost never a good reason to drop a 4032 pixel camera shot into a blog post. It looks identical to a properly resized version, but loads twenty times slower. Worse, on a long-form post with ten images, the difference is enough to cause real damage to your bounce rate.
Thumbnails
Thumbnails are where most sites get sloppy. The temptation is to upload one big image and let CSS shrink it. That works visually, but ships the full file to every user who never sees it at full size.
The right move is to generate or upload a separate thumbnail version. 400 to 600 pixels on the long edge is enough for any thumbnail layout I have ever seen. File size should sit under 80KB.
If your CMS supports responsive images via srcset, even better. The browser picks the right size automatically based on device and viewport. WordPress, Ghost, Webflow and most modern platforms do this out of the box.
Product photos for e-commerce
E-commerce is the one place where the usual rules bend. People zoom into product photos. Customers want to see the stitch detail on a jumper, the texture of a leather bag, the screen of a phone.
1500 to 2000 pixels on the long edge gives enough resolution for the typical zoom interaction without becoming wasteful. Square (1:1) is the dominant grid aspect ratio. Some fashion shops use 4:5. Whatever you pick, keep it identical across the catalogue, mismatched aspect ratios in a product grid look amateur.
Allow file sizes up to about 300KB here. The conversion lift from clear product photos almost always outweighs the load time cost. Just make sure they are WebP if you can. The same product photo at the same visible quality is roughly 30 per cent smaller in WebP than in JPG, which is meaningful when you have 200 of them.
Social share images (Open Graph)
When someone shares your URL on Facebook, LinkedIn, Slack, Discord, Twitter or anywhere else that respects Open Graph tags, the platform pulls one image to display in the preview card. Get this wrong and your share looks broken or generic.
1200 by 630 pixels is the universal answer. It renders correctly on every platform I have tested. Twitter (X) also supports square 1200 by 1200 for a slightly punchier card, but the rectangular version works everywhere, so if you only have time to make one, make that one.
Keep the file under 1MB. There is no benefit to going bigger, and several platforms reject larger files outright. JPG or PNG both work, WebP support in some scraping crawlers is still inconsistent so stick with JPG to be safe.
Email body images
Email is the most constrained environment on the modern internet. Some clients (Outlook 2016, I am looking at you) still render with prehistoric quirks.
Cap image widths at 600 pixels. That is the historical email-safe width and it still works everywhere. Modern Gmail and Apple Mail handle wider images fine, plenty of business inboxes do not.
Keep individual image file sizes under 100KB and the total email size under 100KB if at all possible. Above that, deliverability scores start to drop and some clients will clip the message. Pick photos that work small, do not try to fit a portfolio shot into a newsletter.
A note on Retina and high-DPI screens
Phones and modern laptops have higher pixel densities than the CSS pixel count suggests. A 400 pixel CSS slot on a Retina phone is actually 800 physical pixels.
The pragmatic rule: serve at 2x the layout size for the longest edge. So a 600 pixel slot wants a 1200 pixel image. That is why the 1280 in-content recommendation makes sense for an 800 pixel content column.
You do not need 3x for photo content. The difference between 2x and 3x is invisible on real photographs at normal viewing distances. 3x matters for crisp UI elements (icons, line art, text rendered as image), not for content photography.
Common mistakes
A few patterns I see constantly:
- Uploading the camera original because "you might need the resolution later". You will not, and the live site is paying for it on every visit. Keep the original on your local drive, ship a resized version.
- Saving photos as PNG. PNG is for graphics with sharp edges and transparency. For photos it produces files 5 to 10 times larger than the equivalent JPG. Photos almost always belong in JPG or WebP.
- Lazy-loading the hero image. The hero is the LCP element. Lazy-loading it delays the exact metric Google measures. Below the fold, yes. Above the fold, never.
- Forgetting width and height attributes. This is a free Core Web Vitals win. Most CMSes give it to you automatically. Do not strip the attributes out when you copy-paste a code block.
Where to fix your existing library
If you want to bring an existing site in line with these numbers, start with the homepage. Open the network tab, sort by size, fix the biggest five images. That alone usually moves the page speed score by 20 to 30 points.
For one-off compression, our image compressor targets these defaults out of the box. For specific dimensions, the resize tool takes pixel inputs, percentages, or social-media preset sizes. For converting an existing library from JPG to WebP, the converter handles it in your browser without uploading anything.
Fifteen minutes on your worst page beats six months of "we should really fix the site speed at some point". The work is unglamorous, but the gains are real and they compound across every visit forever.