June 2, 2026 performanceimagesCSS

Stretched and oversized images: how to catch them fast

You can look at a stretched image a hundred times without seeing it. Your brain quietly corrects the proportions. Your users’ brains do too, but the impression of “something’s off” sticks anyway, and Google’s ranking signals don’t correct for anything.

Aspect-ratio bugs and oversized assets are two of the most underreported quality issues on the web. They survive code review not because they’re hard to fix but because they’re nearly invisible to the person who shipped them. Here’s what to look for and how to find it fast.

Rendered resolution vs. intrinsic resolution

Every image on a webpage has two sizes:

Intrinsic resolution — the actual pixel dimensions of the image file (e.g. 1200×800)
Rendered resolution — how large the browser paints it on screen (e.g. 400×300)

The two should stay proportional. When they don’t, you’ve got one of two problems.

A stretched image is one whose rendered dimensions distort the aspect ratio. Take a 1200×800 file (3:2) and render it at 400×350: the displayed ratio is closer to 8:7, so everything is squashed vertically and every face or product shot looks subtly wrong.

An oversized image is one whose file is far larger than the space it fills. Serve a 2400×1600 source to display it at 400×267 and you’re shipping roughly 36× the pixels you need (the source has 6× the width and 6× the height). On a slow connection that’s wasted bandwidth, a slower LCP, and a worse experience on mobile, where it hurts most.

<!-- This looks fine in markup... -->
<img src="hero.jpg" alt="Team photo" style="width: 400px; height: 350px;">

<!-- ...but if hero.jpg is 1200×800, you stretched it AND shipped ~7x the pixels you display -->

The mismatch between intrinsic and rendered size is almost never visible in markup. You have to measure it at runtime.

Why this hurts more than you think

Visual quality

Stretched images break the implicit trust users place in photography. A team photo where everyone looks slightly taller than they are reads as careless, even when nobody can say exactly what’s wrong. On a product page, distorted aspect ratios drag down perceived quality, and on the wrong page that’s enough to dent conversion.

Core Web Vitals

Oversized images hit Largest Contentful Paint (LCP) directly. If your hero image is 3MB and your LCP budget is 2.5 seconds, that one asset is most of your budget gone before anything else loads. Serving a correctly sized image, ideally as WebP or AVIF, is usually the highest-leverage performance fix a content site has available.

Cumulative Layout Shift (CLS) is the other one, and it’s worth being precise about the mechanism. CLS isn’t caused by the wrong resolution; it’s caused by missing dimensions. When an <img> has no width/height attributes and no CSS aspect-ratio, the browser doesn’t know how tall the image will be until the bytes arrive, so it reserves no space for it. The moment it loads, everything below reflows to make room, and that unexpected jump is what CLS measures. Give the browser the dimensions up front and the slot is reserved before the image ever loads.

<!-- Good: explicit dimensions prevent layout shift -->
<img src="photo.jpg" alt="..." width="800" height="533">

<!-- Also good: CSS aspect-ratio reserves space -->
<img src="photo.jpg" alt="..." style="width: 100%; aspect-ratio: 3/2;">

Mobile and responsive layouts

width: 100% in CSS scales an image to fill its container, but it does nothing to the file the browser downloads. On a 375px-wide phone, a 2400px-wide source paints as a small thumbnail on screen while a multi-megabyte file travels down the wire to get there. srcset and sizes exist precisely to fix this, but you can’t write good ones without knowing the rendered sizes first.

How to spot these manually

When I’m checking a single page, the console does the job:

document.querySelectorAll('img').forEach(img => {
  const ratioMismatch = Math.abs(
    (img.naturalWidth / img.naturalHeight) -
    (img.offsetWidth / img.offsetHeight)
  ) > 0.05;

  if (ratioMismatch) {
    console.warn('Stretched:', img.src, {
      intrinsic: `${img.naturalWidth}×${img.naturalHeight}`,
      rendered: `${img.offsetWidth}×${img.offsetHeight}`
    });
  }
});

That catches aspect-ratio distortion but says nothing about oversized images. For those, compare naturalWidth against offsetWidth directly and flag the big discrepancies:

document.querySelectorAll('img').forEach(img => {
  const oversizeFactor = img.naturalWidth / img.offsetWidth;
  if (oversizeFactor > 2) {
    console.warn(`Oversized (${oversizeFactor.toFixed(1)}×):`, img.src);
  }
});

Pasting this into the console on every page gets old fast, and the images that most need checking (heroes, above-the-fold photos, product shots) are exactly the ones that change every sprint.

The practical checklist

When auditing a page for image quality, check each image for:

Aspect ratio — does the rendered ratio match the intrinsic ratio? (within ~5% tolerance for small rounding)
Oversized factor — is naturalWidth / offsetWidth greater than 2? Greater than 1.5 on a mobile viewport?
CLS risk — does the <img> element have explicit width/height, or a CSS aspect-ratio?
Format — is the image served as JPEG/PNG when WebP/AVIF would save 30–50% of file size?

Run that against almost any production site and a handful of images will fail at least one check. Finding them is the hard part; the fixes are mostly mechanical.

Where PxGuard fits in

PxGuard’s Images & Video tool is built for exactly this triage step. It scans the page and surfaces each image’s rendered resolution alongside its intrinsic resolution, so the mismatch is immediately visible — no console scripts, no manual calculations. If an image is being displayed at half its intrinsic width, you see the numbers and can act.

Combined with the aspect-ratio display, it’s the fastest way I know to answer “which images on this page have problems?” before a performance review or a QA pass.

Fixing oversized images

Once you know which images are the problem, the fixes are well-trodden.

Reach for srcset and sizes first. They let the browser pick an appropriately sized file per viewport instead of downloading one giant source everywhere:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
  alt="..."
  width="800"
  height="533"
>

Convert to modern formats. WebP is safe everywhere that matters now, and AVIF, which compresses better than WebP for most content, has broad support too. You rarely have to do this by hand: a build step or an image CDN (Cloudflare Images, Cloudinary, Imgix) will convert and resize on the fly.

And set aspect-ratio in CSS for the layout side of the problem. It reserves the slot before the image loads, so the box doesn’t collapse and reflow on you:

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