Menu
By the ImageSEO team. Updated October 2026.
Quick answer: there is no single best image size for a website. Export each image at the largest width it is displayed at, times two (capped for full-width images), and let the browser pick smaller versions for smaller screens. In practice that means about 1,920–2,560 px wide for a full-width hero, 1,300–1,600 px for an image inside a blog post, 1,200 × 630 px for a social share image, and SVG for logos and icons. File size matters as much as dimensions: compress every image and serve WebP or AVIF where you can.
| Image type | Export size (width) | Aspect ratio | Notes |
|---|---|---|---|
| Full-width hero / header (desktop) | 1,920–2,560 px | 16:9 or wider (e.g. 3:1) | Capped, not ×2; WordPress scales uploads above 2,560 px down automatically |
| Hero on mobile (separate crop) | about 830–1,250 px | Portrait or square, e.g. 4:5 | Use <picture> to swap in a different crop |
| Image inside a blog post | 1,300–1,600 px | 3:2 or 16:9 | For a content column of roughly 650–800 px |
| Featured / share image (og:image) | 1,200 × 630 px | 1.91:1 | Meta’s recommended minimum for high-resolution display |
| Image for Google Discover | at least 1,200 px wide | 16:9 | Google also asks for more than 300,000 pixels in total |
| Product photo | 1,000–2,000 px | 1:1 | Go larger if the store has zoom |
| Background image (CSS) | same as hero | matches the section | Google doesn’t index CSS images, so keep important pictures out of CSS backgrounds; use image-set() or media queries for smaller versions |
| Logo and icons | SVG | – | Vector, sharp at any size |
| Favicon | larger than 48 × 48 px | 1:1 | Google requires a square favicon and recommends more than 48 px |
The numbers in rows 4, 5 and 9, and the note that Google doesn’t index CSS images, come from Meta’s and Google’s documentation. Everything else is a rule of thumb that depends on your theme. The sections below explain how to calculate the right number for your own layout.
A browser lays out a page in CSS pixels (the size the page layout uses, not the screen’s physical pixels). Most phones and many laptops have two or three device pixels for every CSS pixel, which is why an image exported at exactly its displayed width looks soft on them. So:
Export width = displayed width (CSS px) × 2
Two times covers most high-density screens well. Three times is sharper on some phones, but the file gets much bigger for a difference few people notice, so many sites stop at two. For full-width images the rule needs a cap: twice a 1,920 px screen would be 3,840 px, which is far too heavy, so stop at 1,920–2,560 px. Going beyond what the screen needs wastes bandwidth: Lighthouse, Google’s page-speed tool, flags an image when the file is at least 4 KiB bigger than the screen needs (it takes pixel density into account). That check now lives in Lighthouse’s “Improve image delivery” insight.
<img> element in the Elements panel. Chrome shows the displayed size (for example 760 × 507) and the file’s real size.Screen statistics tell you which widths matter most. StatCounter’s worldwide figures for September 2026:
| Desktop resolution | Share | Mobile resolution (CSS px) | Share |
|---|---|---|---|
| 1920 × 1080 | 28.07% | 414 × 896 | 13.35% |
| 1536 × 864 | 10.00% | 360 × 800 | 7.54% |
| 1366 × 768 | 7.95% | 384 × 832 | 7.10% |
| 1280 × 720 | 4.71% | 390 × 844 | 6.05% |
| 2560 × 1440 | 3.95% | 393 × 873 | 4.18% |
Two things follow from this. On desktop, 1,920 × 1,080 is the most common resolution, so a full-width hero exported at 1,920 px covers the most common desktop screens and everything narrower, and 2,560 px covers large and high-density monitors. On mobile, screens are roughly 360–414 CSS pixels wide, so even at three times density a mobile hero needs only about 1,250 px of width. Sending a 2,560 px desktop hero to a phone downloads several times more pixels than it can show.
The hero is usually the largest image on the page and very often the page’s Largest Contentful Paint (LCP): the time it takes for the largest image or text block on the first screen to appear. Google rates an LCP of 2.5 seconds or less as good, so the hero deserves the most care.
<picture> (MDN calls this “art direction”).fetchpriority="high" to the hero if your platform doesn’t do it for you (WordPress usually adds it since 6.3).<picture>
<!-- mobile crop -->
<source media="(max-width: 600px)"
srcset="hero-mobile-830.webp 830w, hero-mobile-1250.webp 1250w"
sizes="100vw">
<img src="hero-1920.webp"
srcset="hero-1280.webp 1280w, hero-1920.webp 1920w, hero-2560.webp 2560w"
sizes="100vw"
width="1920" height="1080"
alt="Describe what the hero photo shows"
fetchpriority="high">
</picture>
Images inside an article are limited by the width of the text column, usually about 650–800 px on desktop. Export them at about twice that, so 1,300–1,600 px wide, and let srcset serve smaller copies to phones. A 3:2 ratio suits photos; 16:9 suits screenshots of wide interfaces. If your theme has a wider “featured image” above the article, size that one like a hero.
For the image that represents the article when it is shared, use 1,200 × 630 px. Meta recommends at least that size for sharp display on high-resolution devices and an aspect ratio close to 1.91:1. For Google Discover, Google asks for images at least 1,200 px wide, with more than 300,000 pixels in total, ideally 16:9, plus the max-image-preview:large setting, which WordPress turns on by default for public sites.
A banner across the full width follows the hero rules. Background images set in CSS are different in one important way: Google doesn’t index CSS images. A photo that matters for search, such as a product, your team or your work, should be an <img> element with alt text, not a CSS background. Keep CSS backgrounds for textures, gradients and decorative photos.
CSS backgrounds can’t use the srcset attribute, but CSS has its own tools for the same job: image-set() for different pixel densities and media queries for different screen widths. Use them so phones don’t download the desktop file.
Neither Google nor the web standards set a maximum file size. Dimensions and compression together decide it. The same 1,920 px photo can differ several times in file size depending on format and compression settings. Instead of chasing a number:
You don’t have to pick one size for every screen. With srcset and sizes you list several widths of the same image and tell the browser how wide it will be displayed; the browser then downloads the smallest file that still looks sharp. MDN calls this “resolution switching”. These attributes work in all modern desktop and mobile browsers.
WordPress does much of this automatically. When you upload a photo it creates copies at 150 × 150 (thumbnail), 300, 768, 1,024, 1,536 and 2,048 px (only the sizes smaller than the original), and it adds srcset to images in your content. Uploads larger than 2,560 px are scaled down, with the original kept. What WordPress doesn’t do by default is convert JPEG and PNG to WebP or AVIF or compress your original; a plugin handles that. See our comparison of WordPress image optimization plugins.
Not very common, even on big sites. In our crawl of the homepages of the 10,000 most popular websites (Tranco ranking, 5,408 homepages with images, 310,668 images, 11 August 2026) we found:
| Check | Share of images |
|---|---|
Uses srcset |
16.6% |
Sets both width and height |
40.2% |
Sets neither width nor height |
56.4% |
| Has a .webp or .avif file name | 8.7% |
Has loading="lazy" |
41.8% |
Method and limits: homepages only, one crawl date, static HTML without running JavaScript, and we read attributes only, without downloading the image files. Sites that add these attributes with JavaScript are therefore under-counted. The format is read from the file extension, so images converted by a CDN or offered through <picture> sources are not counted; 8.7% is a floor.
When an image has no width and height attributes, the browser doesn’t know how much space to reserve, and text jumps down when the image arrives. That jump is measured as Cumulative Layout Shift, one of the Core Web Vitals. Setting both attributes (to the file’s real size; CSS can still make it responsive with height: auto) lets the browser reserve the right box from the start. More than half of the homepage images in our crawl skip this.
Indirectly. Google says its ranking systems look to reward pages with a good page experience, and Core Web Vitals such as LCP are part of that. Google is also clear that it always seeks to show the most relevant content, even when page experience is weak, and that good Core Web Vitals scores don’t guarantee top rankings. Oversized images rarely sink a page on their own, but they slow it down for real visitors, and when many pages compete for the same search, that can make a difference.
For the image itself to rank in Google Images, size helps less than what Google can understand about it: a descriptive file name, good alt text and relevant text around the image. Our step-by-step tutorial on optimizing images for SEO covers those parts, and the full checklist is in our image SEO guide.
<picture>srcset and sizes in place (automatic in WordPress)width and height set on every image<img> elements with alt text, not CSS backgroundsOur free image SEO audit scans up to five pages of any site and lists every image that has no alt text. If you run WordPress, the ImageSEO plugin writes alt text and file names in bulk; it doesn’t resize or compress images, so pair it with a compression plugin. If you’re deciding between tools, see ImageSEO vs EWWW or all comparisons.
Export each image at about twice the width it is displayed at, capped at 1,920–2,560 px for full-width images. Typical results: 1,920–2,560 px for a full-width hero, 1,300–1,600 px for blog images, 1,200 × 630 px for social sharing and SVG for logos.
About 1,920 px wide for most desktop screens, up to 2,560 px for large or high-density monitors, plus a separate portrait or square crop of roughly 830–1,250 px wide for phones.
About 1,300–1,600 px wide for an image in a typical 650–800 px text column, and 1,200 × 630 px for the image used when the post is shared.
The same width as a hero (1,920–2,560 px), with smaller versions for phones served through CSS media queries or image-set(). Keep important photos out of CSS backgrounds, because Google doesn’t index CSS images.
There is no official limit. Get the dimensions right, compress, use WebP or AVIF, and check that the page’s LCP stays at 2.5 seconds or less.
No. Screens use pixels, so only the width and height in pixels matter. A 1,600 px image looks the same at 72 or 300 DPI.
