Web Hero Image Size: The Complete Guide to Width, Height, and Responsive Delivery

There is no universal web hero image size. Choose dimensions from the hero slot your design actually renders, then provide candidates for that slot and the device pixel density. Use srcset and sizes so the browser can choose an appropriate file, use <picture> when mobile needs a different crop, and declare intrinsic dimensions so the page reserves space before the image loads.

A practical starting point is to measure the rendered hero at each breakpoint. If the slot is 1,200 CSS pixels wide on desktop, provide a candidate around 1,200 pixels for a 1x display and around 2,400 pixels for a 2x display, plus smaller candidates for narrower layouts. The exact files depend on your crop, format, compression, and delivery pipeline.

What size should a web hero image be?

Start with the rendered slot, not a preset such as “1920×1080”. A full-width hero that renders at 1,440×600 has different requirements from a contained hero that renders at 960×540. Measure the CSS box at the breakpoints that matter, record its aspect ratio, and create image candidates that cover those widths.

Question	Decision
How wide is the slot?	Use the hero container’s rendered CSS width at each breakpoint.
What is the crop?	Keep a consistent ratio when possible; use a separate mobile crop when the composition requires it.
Which pixel densities matter?	Offer candidates around 1x and 2x the rendered CSS width. Add an intermediate width when your breakpoints need it.
Is the hero the LCP element?	Make it discoverable in HTML, avoid lazy-loading it, and consider a high fetch priority.
How much data should be sent?	Send the smallest candidate that remains sharp at the actual rendered size.

Google’s responsive-image guidance explains that serving desktop-sized images to mobile devices can use 2–4× more data than necessary. That is a comparison for serving oversized desktop files to mobile, not a guaranteed saving for every site. See Serve responsive images.

Measure the rendered hero slot

1. Open the page at each important breakpoint.
2. Inspect the hero image or its container in browser developer tools.
3. Record the CSS width and height, including any max-width, padding, or grid column constraints.
4. Record the intended object position: for example, centered, top aligned, or focused on a person’s face.
5. Check whether the hero is full bleed, contained, or clipped by an overflow rule.

For a hero that is 1,200 CSS pixels wide and 500 CSS pixels tall on desktop, useful source candidates might be 640×267, 960×400, 1,200×500, 1,800×750, and 2,400×1,000. Those are examples of a 12:5 ratio; they are not universal presets. Your source files should follow your measured ratio and crop.

Use srcset and sizes for responsive width

srcset lists candidate files. A width descriptor such as 1200w tells the browser the intrinsic width of that candidate. sizes describes how wide the image is expected to render; CSS still controls the actual display size. The browser combines both values with viewport dimensions and device pixel ratio to select a resource. See Google’s responsive images guide.

<img
  src="/images/hero-1200.jpg"
  srcset="
    /images/hero-640.jpg 640w,
    /images/hero-960.jpg 960w,
    /images/hero-1200.jpg 1200w,
    /images/hero-1800.jpg 1800w,
    /images/hero-2400.jpg 2400w
  "
  sizes="100vw"
  width="1200"
  height="500"
  alt="A cyclist riding along a coastal road"
>

If the hero is inside a centered container rather than full width, make sizes match that layout:

<img
  src="/images/hero-1200.webp"
  srcset="
    /images/hero-640.webp 640w,
    /images/hero-960.webp 960w,
    /images/hero-1200.webp 1200w,
    /images/hero-1600.webp 1600w
  "
  sizes="(max-width: 760px) calc(100vw - 32px), 1200px"
  width="1200"
  height="500"
  alt="A cyclist riding along a coastal road"
>

Do not use a guessed sizes value. If the image renders at 760 pixels but you declare 100vw on a 1,440-pixel viewport, the browser may select a larger file than necessary. If you declare a value smaller than the real slot, the selected file may look soft.

Choose aspect ratio and crop deliberately

Keep the source ratio, declared width/height, and CSS treatment consistent. If your design uses a fixed-height hero, crop with object-fit: cover and set object-position to protect the important subject.

.hero {
  aspect-ratio: 12 / 5;
  overflow: hidden;
}

.hero img {
  display: block;
  width: 100%;
  height: 100%;
  object-fit: cover;
  object-position: 50% 40%;
}

When the mobile composition is genuinely different, use art direction with <picture>. This can serve a portrait or tighter crop rather than forcing the desktop composition into a narrow slot.

<picture>
  <source
    media="(max-width: 760px)"
    srcset="
      /images/hero-mobile-480.webp 480w,
      /images/hero-mobile-800.webp 800w
    "
    sizes="100vw"
  >
  <source
    type="image/webp"
    srcset="
      /images/hero-desktop-1200.webp 1200w,
      /images/hero-desktop-1800.webp 1800w,
      /images/hero-desktop-2400.webp 2400w
    "
    sizes="100vw"
  >
  <img
    src="/images/hero-desktop-1200.jpg"
    width="1200"
    height="500"
    alt="A cyclist riding along a coastal road"
  >
</picture>

Use srcset alone when every viewport uses the same image composition at different sizes. Use <picture> when you need explicit source selection, a different crop, or format-specific sources. The web.dev responsive images guide covers both patterns.

Reserve space to prevent layout shift

Include truthful width and height attributes on the image. Browsers use their ratio to reserve space before the file arrives, reducing cumulative layout movement. The same principle can be expressed with CSS aspect-ratio. See Serve images with correct dimensions.

.hero img {
  width: 100%;
  height: auto;
  aspect-ratio: 12 / 5;
  object-fit: cover;
}

Do not put fake dimensions on an image with a different intrinsic ratio unless you also intentionally crop it. A mismatch can distort the image or reserve the wrong amount of space.

Load a hero image efficiently

Make the LCP image discoverable

If the hero is likely to be the Largest Contentful Paint element, reference it directly in the initial HTML. A CSS background or JavaScript-injected image can be discovered later. Google’s LCP guidance explains why late discovery delays loading.

<link
  rel="preload"
  as="image"
  href="/images/hero-1200.webp"
  type="image/webp"
  fetchpriority="high"
>

Use preload only when the resource is genuinely critical and make the preload consistent with the image that will be used. For responsive preloads, browsers that support it can use imagesrcset and imagesizes; otherwise, the ordinary img markup remains the source of truth.

Use fetch priority carefully

fetchpriority="high" is a hint for a critical hero, not a replacement for correct dimensions, responsive candidates, or fast server delivery. Do not mark every image high priority. See Optimize resource loading with the Fetch Priority API.

<img
  src="/images/hero-1200.webp"
  srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w, /images/hero-2400.webp 2400w"
  sizes="100vw"
  width="1200"
  height="500"
  fetchpriority="high"
  alt="A cyclist riding along a coastal road"
>

Do not lazy-load the above-the-fold hero

Lazy-loading is useful for images below the fold. Applying loading="lazy" to the main hero can postpone the request and hurt LCP. Let the browser discover the hero immediately unless your layout places it below the initial viewport.

Formats, compression, and delivery

• Generate the same crop in several widths rather than sending one oversized master file.
• Use a modern format supported by your delivery path, with a fallback when needed.
• Compress photographic images and inspect the result at the actual display size. A visually lossless setting is often a better target than a fixed byte number.
• Keep filenames or URLs cacheable when the content is immutable; change the URL when the image changes.
• An image CDN is optional. It can automate resizing and format negotiation, but responsive HTML does not require a paid CDN. Choose one only when it solves a real delivery or transformation problem.

Common hero-image configurations

Layout	Typical sizes	Key concern
Full-bleed hero	100vw	Generate widths covering the viewport range and protect the focal point during cropping.
Centered max-width container	(max-width: 760px) calc(100vw - 32px), 1200px	Do not make the browser assume the image is viewport width when the container is capped.
Two-column hero	(max-width: 760px) 100vw, 50vw	The desktop image slot may be half the viewport, while mobile becomes full width.
Fixed-height cover crop	Match the container width	Use accurate ratio metadata and object-position to avoid losing the subject.

DIY implementation checklist

• Measure the hero slot at desktop, tablet, and mobile breakpoints.
• Choose the intended aspect ratio and focal point for every crop.
• Export several candidate widths, including a high-density option where useful.
• Write a truthful srcset and sizes.
• Use <picture> for a deliberate mobile crop or format selection.
• Add accurate width and height attributes or aspect-ratio.
• Keep the LCP image in HTML, avoid lazy-loading it, and consider fetchpriority="high".
• Run Lighthouse and inspect the properly sized images and LCP opportunities.
• Check real devices and slow connections for sharpness, crop, and layout stability.

Or skip the browser setup

If your job is to capture a rendered page or hero for QA, documentation, previews, or an automated workflow, ScreenshotNeo returns a screenshot or PDF from one GET request. Its capture flow accepts cookie and consent banners, removes more than 60 known consent platforms plus newsletter popups and chat widgets, and each step can be turned off. Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed; response headers identify the page verdict and whether the request was billed. It also provides an MCP server for Claude, Cursor, and other MCP clients.

See the ScreenshotNeo API documentation for the full option list.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://your-site.example -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://your-site.example"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://your-site.example'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const file = Buffer.from(await res.arrayBuffer());
require('fs').writeFileSync('shot.webp', file);

ScreenshotNeo supports full-page captures with lazy images loaded, CSS-selector element capture, dark mode, device presets and custom viewports, retina scale, custom CSS and JavaScript, click and wait actions, blocked requests and resource types, headers, cookies, user agents, authorization, timezone, geolocation, transparent backgrounds, resizing, caching with a chosen TTL, signed links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, usage reporting, PDF options, HTML/CSS-to-image, and an OpenAPI specification. Parameters used by other screenshot APIs also work to ease migration.

The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots; yearly billing gives two months free, and every feature is available on every plan. Create a free ScreenshotNeo account.

Troubleshooting

The hero looks blurry on high-density screens

Cause: the largest candidate is close to the CSS width, or sizes understates the rendered slot. Fix: add a candidate around 2× the rendered CSS width, verify its width descriptor, and make sizes match the real layout.

The browser downloads a desktop-sized file on mobile

Cause: missing or inaccurate sizes, or a single fixed src. Fix: provide width-descriptor candidates and describe the mobile slot first in sizes.

The image is stretched

Cause: the declared dimensions or CSS ratio does not match the source, or both width and height are forced without cropping. Fix: keep metadata truthful; use object-fit: cover when a deliberate crop is intended.

The page jumps when the hero loads

Cause: no intrinsic dimensions or aspect ratio was reserved. Fix: add accurate width and height attributes or an equivalent aspect-ratio rule.

The hero hurts LCP

Cause: it is hidden behind JavaScript or a CSS background, lazy-loaded, oversized, or delayed by a slow image origin. Fix: put it in initial HTML, remove lazy-loading for an above-the-fold hero, serve a correctly sized candidate, and consider preload plus fetchpriority="high".

The mobile crop removes the subject

Cause: the desktop crop is being reused in a narrow container. Fix: create a mobile-specific crop with <picture>, then set a deliberate object-position for any remaining cover crop.

ScreenshotNeo returns an unexpected page

Cause: the target may show a consent dialog, bot check, blank response, or timeout, or the page may need waits, headers, cookies, JavaScript, or a specific viewport. Fix: review the X-Page-Verdict and X-Billed response headers, then configure the relevant wait, selector, device, request blocking, cookie, header, or script option in the docs.

Performance, reliability, and cost notes

• Performance: candidate widths reduce transferred bytes; the browser can avoid downloading a desktop file for a small viewport.
• LCP: a responsive hero can reduce resource load duration when it is the LCP element. Keep the critical request discoverable and prioritize only the genuinely critical image.
• Reliability: test every crop at real breakpoints, on slow networks, and with images temporarily disabled to verify that the layout still reserves space.
• Caching: immutable, versioned image URLs improve repeat loads. For screenshot automation, choose a cache TTL that matches how often the target changes.
• Cost: responsive delivery lowers unnecessary transfer; an image CDN is optional. ScreenshotNeo bills only clean shots and identifies billing in response headers, while cache hits and failed or unusable captures cost nothing.

FAQ

Is 1920×1080 the correct hero image size?

Only if it matches your rendered slot, crop, and density needs. It is a source candidate, not a universal rule.

Should every hero use a 16:9 ratio?

No. Choose the ratio your design needs. A wide banner, editorial feature, and mobile portrait hero can all use different ratios.

Do I need an image CDN?

No. You can generate variants and serve them with ordinary HTML. A CDN is useful when you need automated transformations, format negotiation, or delivery at larger scale.

Should a hero have loading="lazy"?

Usually not when it is above the fold or the LCP element. Lazy-load images that begin below the initial viewport.

What should I measure after publishing?

Check the selected resource in browser developer tools, delivered bytes, crop at each breakpoint, layout stability, and LCP. Lighthouse can identify images that are still larger than their rendered dimensions.