Hero Image Size: Optimal Dimensions for Above-the-Fold

The recommended dimensions, aspect ratios, and file-size budgets for hero images that look sharp on every screen and don't tank your Core Web Vitals scores in the process.

Looking for sizes for other elements? See our full image size reference.

Quick Answer

1920×1080 pixels at 16:9 for the desktop hero. This single number covers 1080p displays at 1×, 720p displays at 2×, and most laptop screens cleanly. Save as WebP at quality 80 and target 200–400 KB. Add a smaller srcset variant for mobile.

That is the answer for most sites. The longer version below covers when to deviate — ultrawide layouts, mobile art direction, retina-density displays, and the performance implications of heroes specifically.

Recommended Hero Sizes by Use Case

Why 1920×1080

Three reasons the 1920×1080 default has stuck around since the mid-2010s:

• Most desktop viewports are still around this size. Statcounter has been showing 1920×1080 as the most common screen resolution worldwide for a decade. A hero image at exactly this size renders 1:1 — no upscaling, no downscaling, sharpest possible result on the most common screen.
• It's a clean 2× of 960×540. When you scale down for mobile or constrained layouts via srcset, you get round numbers that browsers handle without sub-pixel artifacts.
• It hits a reasonable compression sweet spot. A well-compressed 1920×1080 WebP is comfortably under 400 KB; a 4K (3840×2160) version of the same image is 1–2 MB. The visual quality difference on a 1080p screen is zero.

The argument for going to 2560×1440 is retina rendering on 1440-pixel-wide containers, which exists but is rare for hero slots specifically — most hero containers are constrained by viewport, not designer-set width. Save the bytes for elements where retina density actually matters (product photos, icons in tight grids).

Hero Image Height and Aspect Ratio

The width question is settled: export at 1920. Height is the decision people actually get stuck on, and it is the one that sets your aspect ratio — a full-bleed hero is scaled to fill the container width, so the height you export decides the shapeof the band, not how sharp it looks. Pick the band you want on a laptop, then read the ratio off it.

Is 1920×700 a good hero size?

Yes, for a band-style hero rather than a full-screen one. At 2.74:1 it renders about 498 pixels tall on a standard 1366-wide laptop — a wide strip above the fold with room for content underneath, which is exactly what most marketing pages want. It also carries 35% fewer pixels than 1920×1080, so it is cheaper for Largest Contentful Paint, not worse. Nothing about a shorter hero is a compromise on quality; the width is what determines sharpness, and it has not changed.

What a short band costs you is mobile. Scaled to a 390-pixel phone, 1920×700 lands at roughly 142 pixels tall. Below about 200 pixels a hero stops reading as an image and starts reading as a divider — the subject becomes unrecognisable and any text baked into it is unusable. If your band is 700 or shorter, pair it with a portrait crop via the picture element rather than letting the desktop shape scale down.

One trap worth naming: do not choose a short export height and pin the section to a fixed CSS height. The image gets cropped twice — once by you in the export, once by object-fit: cover in the browser — and the subject drifts out of frame on viewport widths you never tested. Let the aspect ratio drive the section height, not the other way round.

Mobile: Art Direction or Scaling?

The single biggest mobile-hero mistake is letting a 16:9 desktop image render unchanged on a portrait phone screen. On a 375-pixel iPhone viewport, a 1920×1080 image at full width displays as 375×210 — a thin sliver. Subjects get tiny, important elements get cropped or lost.

Two solutions:

• If the desktop crop survives center-cropping to portrait: srcset alone is enough. The browser picks a smaller variant, displays it at the correct size, and you save bytes without changing the framing.
• If the desktop crop fails on portrait (faces cut off, text cropped, key visual elements lost): use the <picture> element with art-direction sources. This swaps the entire image based on viewport, letting you ship a portrait-cropped or recomposed mobile version. The cost is maintaining two creative variants of the same hero.

<picture>
  <source media="(max-width: 768px)" srcset="/hero-mobile.webp">
  <source media="(min-width: 769px)" srcset="/hero-desktop.webp">
  <img src="/hero-desktop.webp" alt="..." width="1920" height="1080">
</picture>

Email Hero Images

Email is the one place where the web answer is wrong. The standard email hero is 600 pixels wide, usually 250–400 pixels tall depending on the template. Almost every email client caps content width at 600–640 pixels regardless of the recipient's screen, so anything wider is cropped or scaled down and you have paid the file-size cost for nothing.

Serve it at 1200 pixels wide for retina and let the template scale it to 600, exactly as you would on the web. The difference is the ceiling: on a website the slot grows with the viewport, in email it does not.

• Display width: 600 px (some templates use 640)
• File to serve: 1200 px wide for 2× displays
• Height: 250–400 px is typical for a header band
• File size: keep under 200 KB — many clients are opened on mobile data

Set explicit width and height attributes, and never rely on the image alone to carry the message. Several clients block images by default, so the email still has to make sense when the hero does not load.

File Size Targets

Hero images are the largest single asset on most homepages. Reasonable targets:

• 1920×1080 desktop hero (WebP, q80): 200–400 KB
• Same image as JPG fallback (q80): 300–500 KB
• Mobile companion (750×1000 WebP): 80–150 KB
• 4K-targeted hero (2560×1440 WebP): 400–700 KB — already crossing into "costing you LCP" territory

Above ~800 KB the image starts measurably hurting page load. Above 1.5 MB Google Lighthouse will flag it. Above 3 MB you have a real Core Web Vitals problem.

Hero Images and Core Web Vitals

On most homepages and landing pages, the hero image is the Largest Contentful Paint (LCP) element — the single largest visible thing the browser has to render before the page feels "done". LCP is one of the three Core Web Vitals Google uses as a ranking signal. Slow hero = slow LCP = lower rankings.

Three concrete things that improve hero LCP:

• Don't lazy-load it. Lazy loading defers image download until the browser estimates the image is about to be visible. The hero is visible immediately. Setting loading="lazy" on a hero is one of the more common ways to break LCP — it appears as if you optimized something but actually slowed it down.
• Use fetchpriority="high" on the hero image tag. Tells the browser to download this image with higher priority than other resources on the page. Available in all modern browsers as of 2023.
• Preload it. Add <link rel="preload" as="image" href="/hero.webp"> to the document head. The browser starts downloading the hero before it has even parsed the body, shaving 100–500 ms off LCP on slower connections.

Common Mistakes

• Using PNG for a photographic hero. PNG is lossless, which means a JPG-suitable image (a photograph) becomes 5–10× larger as a PNG with no visible quality benefit. Use JPG, WebP, or AVIF for photos. PNG only when transparency or sharp edges matter.
• Lazy-loading the hero. Common in image-heavy templates that lazy-load everything by default. Override the default for the hero specifically.
• Shipping at 4000+ pixels wide. Most heroes are constrained by viewport width. A 4000-pixel hero displayed in a 1920-pixel container is the same visible image with 4× the file size. Cap source dimensions at the largest realistic viewport.
• Forgetting the alt attribute. Hero images often have decorative roles, but if your hero contains text overlaid on it, the alt should describe the image content (the underlying photograph), not the overlay text. Empty alt is OK when truly decorative but rarely correct for editorial hero images.
• Skipping width and height attributes. Browsers reserve space for the image only after they know its dimensions — without explicit width/height, layout shifts happen as the hero loads, hurting Cumulative Layout Shift (another Core Web Vital). Always set both.
• Stretching a small source to fit a large container. If your hero container is 1920 pixels wide and your source is 800 pixels, the browser upscales — and upscaled images look soft on every device. Match source to displayed size, or go larger (never smaller).

Tools That Help

Hero images are heavy by their nature, and the highest-leverage thing you can do is compress them well at the source plus serve via a CDN that handles format negotiation.

Frequently Asked Questions

Related Guides

• Best image sizes for websites in 2026 — full reference covering hero, blog, social, and more.
• Shopify image sizes: complete guide — Shopify-specific hero, banner, and product image dimensions.
• WordPress featured image size — featured-image dimensions per theme, including hero/header use cases.
• Find oversized images on your website — heroes are the most common culprit; this covers the audit workflow.
• Natural vs rendered image dimensions — the technical concept behind "your hero is shipping at 3× the size it's displayed at".
• Open Graph image size — your hero often doubles as the og:image for social shares.
• Social media image sizes — per-platform profile, post, and cover dimensions for social channels.
• Squarespace image sizes — Squarespace banners are CSS-driven heroes; specific platform reference.
• Webflow image dimensions — Webflow hero sections plus the responsive variant system.

Last updated: May 6, 2026