Aspect Ratio Calculator

Why aspect ratios matter for responsive images

The layout shift problem

When a browser starts rendering a page, it doesn't know how big an image will be until the file actually downloads — which can take hundreds of milliseconds. If you don't tell the browser the image's dimensions up front, it reserves zero space for it, then once the image loads, everything below it gets pushed down. The header you were about to click jumps. The button you were aiming for moves. This is called Cumulative Layout Shift (CLS), and it's one of Google's three Core Web Vitals — it directly affects your search ranking.

The fix: tell the browser the image's aspect ratio before it loads, so it can reserve the correct amount of space.

Why this gets worse on smaller screens

On a 1920px desktop, an image that's 1200px wide takes up 62% of the viewport. If it shifts the page by 200px when it loads, that's annoying but not catastrophic — the user can still see most of the page.

On a 375px mobile screen, that same image scales down to fill 100% of the viewport — and shifts can push every other element off-screen. The user taps where a button was, but it's now somewhere else. Mobile traffic punishes layout shift much more than desktop, and Google weighs mobile CLS more heavily because of mobile-first indexing.

The right way to do it

Specify width and height as HTML attributes on every <img>, even when CSS scales the image responsively:

<img
  src="hero.jpg"
  width="1920"
  height="1080"
  alt="…"
  style="width: 100%; height: auto;"
>

The width/height attributes don't lock the image to those pixel dimensions — they tell the browser the aspect ratio. The browser then reserves aspect-ratio: 1920 / 1080 worth of space at whatever the CSS-computed width is. The image scales fluidly with the viewport AND there's no layout shift. This pattern was reintroduced as a recommended practice by web.dev in 2020 specifically to address CLS.

The modern alternative: the CSS aspect-ratio property

For images styled entirely via CSS — or for video/iframe embeds — you can declare the aspect ratio directly:

.hero-image {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

This gives the browser the same hint without relying on HTML attributes. Useful when the image source is dynamic (e.g. a CMS thumbnail at unknown dimensions) but you know the visual ratio you want. Reference: MDN — aspect-ratio.

Different ratios at different breakpoints — art direction

A 16:9 landscape hero image looks great on a desktop, but on a 9:16 phone, it becomes a tiny strip with huge margins above and below. The fix is to serve a different crop or even a different image at each breakpoint, using the <picture> element:

<picture>
  <source media="(max-width: 600px)" srcset="hero-mobile.jpg" />
  <source media="(max-width: 1200px)" srcset="hero-tablet.jpg" />
  <img src="hero-desktop.jpg" alt="…" width="1920" height="1080" />
</picture>

Mobile gets a 1:1 or 9:16 crop with the subject centered. Tablet gets a 4:3. Desktop gets the wide 16:9. Same content, intentional cropping at each ratio. Reference: MDN — Responsive images and web.dev — Responsive images.

Common pitfalls

• Removing width/height "because we use CSS" — this is the #1 cause of CLS. Keep the HTML attributes; CSS still wins for layout, but the browser uses the attributes to reserve space.
• Same ratio at every breakpoint — a 16:9 landscape on a phone wastes 70% of vertical space. Use <picture> with different sources for art direction.
• Wrong-ratio thumbnails — if your CMS generates 200×200 square thumbnails but the design slot is 16:9, the image gets letterboxed or distorted. Match the source ratio to the slot ratio.
• Mismatched width/height attributes — if the attributes say 1920×1080 but the actual file is 1600×900, the browser reserves the wrong shape and you get a tiny shift when the image loads. Always match.

Common aspect ratios & where they're used