The selection happens before the page has a layout. A preload scanner reads the raw HTML while the parser is still working and the stylesheet has not necessarily arrived, so at the moment the browser chooses a file it does not know how wide the image will be drawn - and it will not go back and check.

sizes is how you tell it in advance. It is not a hint and it is not documentation: it is the width the browser uses in the arithmetic, and if it disagrees with the CSS then the CSS is the thing that loses.

Leave sizes off entirely and the browser uses 100vw. Every image on the page is then declared full-bleed, whatever it looks like - which is why a sidebar thumbnail can arrive as a 1600px file.

The arithmetic, in the order it runs

1. Resolve sizes. The media conditions are read left to right and the first one that matches wins - the rest are not consulted, the same rule <picture> uses.
2. Multiply by device pixel ratio. A 400px box on a 2× screen needs an 800px file.
3. Pick a candidate. The smallest w in the srcset that is at least that number. If none reaches it, the largest one.

Three consequences follow from that and each of them is a bug somebody has shipped. A sizes that is too large is expensive on every device, because step 3 rounds up from an inflated number. A sizes that is too small is worse than too large on a retina screen, because a blurry image is visible in a way a wasted 900kB is not. And a candidate list with no width above the computed need means the largest file, on the smallest phone.

The four ways it is written wrong

A percentage

sizes="50%" is invalid and is discarded, which puts you back on 100vw. Percentages of what? There is no containing block yet. Use vw, px, em or a calc() of them.

The CSS width, copied

max-width: 800px on an image drawn at half the viewport is sizes="(min-width: 1600px) 800px, 50vw", not sizes="800px". The breakpoint in sizes is the viewport width at which the cap starts binding, and it is arithmetic rather than one of your design breakpoints.

Mixed descriptors

srcset="a.jpg 2x, b.jpg 800w" is one list with two grammars in it. Pick one: x descriptors ignore sizes completely and are for a fixed-size image, w descriptors are for one that responds.

Forgetting the container

An image inside a max-width: 72ch column is not 100vw on a wide screen and it is not 50vw on a narrow one. This is the case sizes models worst, and the one worth measuring rather than deriving.

a half-width image capped at 800px, written out

<img
  src="/img/hero-800.jpg"
  srcset="/img/hero-480.jpg 480w,
          /img/hero-800.jpg 800w,
          /img/hero-1200.jpg 1200w,
          /img/hero-1600.jpg 1600w"
  sizes="(min-width: 1600px) 800px, 50vw"
  width="800" height="450"
  alt="">

width and height are on it for a different reason and are not optional either: without them the box has no aspect ratio until the bytes land, and the layout shift that follows is the one thing on this page a visitor actually notices.

Why the number never looks wrong in DevTools

Two behaviours hide it. A browser that has already downloaded the 1600px file will keep using it after a resize rather than fetching something smaller - going up is a visible improvement, going down is a visible regression, so re-selection is one-way. And a desktop screen at 2× reaches the largest candidate honestly, which means the machine you are testing on is the one machine where the bug is invisible.

The measurement that settles it is the file the page actually fetched against the box it was actually drawn in, taken on a real viewport rather than in a resized window. Those two numbers are not printed together anywhere in a browser's own tooling, and the ratio between them is the whole finding.

sizes="auto" moves the arithmetic to after layout and gets it exactly right. It requires loading="lazy" on the same element - which excludes anything above the fold, so the images that cost the most are the ones it cannot help with. Check support before it is your only sizes.

What to do about it on Monday

• Write sizes from the drawn width, not the intrinsic one, and keep the media condition in viewport terms.
• Cap the candidate list at twice the largest drawn width. A 1600px file for an 800px box covers 2×; a 2400px one covers nobody.
• Test at 1× on a narrow viewport with a cold cache. That is the only configuration where a wrong sizes is visible.
• Check the ratio of bytes fetched to pixels drawn, per image, rather than the total page weight - one bad sizes on a repeated thumbnail outweighs everything else on the page.

The first three are worth doing by hand. The fourth is a number, it is different on every breakpoint, and it is the reason this note has a calculator attached to it.

Two things have to be true before sticky does anything at all, and both are easy to satisfy by accident and easy to break by accident.

1. A threshold. At least one of top, right, bottom or left must be set. Without one there is no line to stick to, and the element scrolls away exactly as if nothing were set.
2. A scrollport that actually scrolls. Sticky positions the element inside the nearest scrolling ancestor - and once an ancestor establishes one, that box is the whole world the element can travel in.

Everything below is a variation on the second one.

The ancestor properties that end it

overflow: hidden

The commonest by a distance, and usually written as overflow-x: hidden on body to hide a sideways scroll. It establishes a scrollport with no scrolling in it, so the sticky element sticks inside a box that never moves. The two bugs are the same bug.

overflow: auto or scroll

Same mechanism, stated deliberately. The element now sticks within that container rather than within the page - correct behaviour, and rarely the intended one.

overflow: clip

The exception worth knowing. clip cuts the overflow without establishing a scrollport, so sticky survives it. It is the right property for the full-bleed case that produced the hidden in the first place.

A parent with no room

Sticky travels inside its own parent, never past it. A header whose parent is only as tall as the header has nowhere to go, and this is what a flex or grid item usually is by default.

contain: paint

Establishes a containing block for the same reason overflow does. Added for performance, and it takes sticky with it.

Two columns, the same header CSS in both. Scroll them. The right one has a wrapper with overflow: hidden between the header and the scrolling box, and that is the entire difference. - runs on the page itself.

Finding the ancestor

The search is mechanical, which makes it worth doing in one line rather than by opening panels:

every ancestor that could be the reason

const blockers = [];
let node = document.querySelector('.your-sticky-thing');

while ((node = node.parentElement)) {
  const s = getComputedStyle(node);
  const overflow = `${s.overflowX} ${s.overflowY}`;
  if (/hidden|auto|scroll/.test(overflow) || s.contain.includes('paint')) {
    blockers.push([node, overflow, s.contain]);
  }
}

blockers;
// The first entry is the one. Everything after it is above the
// scrollport and cannot have caused anything.

The first result, not the last. Once one ancestor establishes a scrollport, the ancestors above it are outside the element's world entirely - and a list read bottom-up sends people to change overflow on html, which is how a one-element bug turns into a page-wide one.

The fix that is almost always right

clip instead of hidden, scoped instead of global

/* Was: */
body { overflow-x: hidden; }

/* Becomes, on the element that actually overflows: */
.hero-decoration {
  overflow-x: clip;
}

clip does what the author meant - hide what sticks out - without the side effect they did not ask for. And scoping it to the offending element rather than the document means the next sticky thing anybody adds is not born broken.

If the cause is a parent with no height rather than an overflow, the fix is on the parent: give it the height the sticky element is meant to travel through, usually by removing an align-items: stretch assumption or setting height: 100% on the intermediate wrapper.

What sticky is not

• Not fixed. A fixed element leaves the flow and is positioned against the viewport; a sticky one keeps its space and its place in the layout, which is why it does not cause a jump when it engages.
• Not a scroll listener. It is laid out by the engine, off the main thread, and it cannot be janky. Anything replacing it with a scroll handler and a class toggle is slower and worse in every browser.
• Not free of stacking. A sticky element creates a stacking context, so its children sort among themselves. A dropdown inside a sticky header cannot paint above something outside it, whatever number it carries.

That last one is the same trap as z-index: 9999, arriving from a different direction. Sticky is on the list of properties that open a stacking context, and almost nobody knows it is.

Before anything else, one check that costs five seconds: z-index does nothing at all on an element whose position is static. That is the default. If the property is not being read, no value of it is going to help.

The exception is a flex or grid child, where z-index applies without positioning. It is the one place the property works on a static element, and it is a pleasant surprise exactly once.

Past that, raising the number stops helping, and it stops helping abruptly rather than gradually. The reason is that z-index does not sort an element against the page. It sorts it against its siblings, inside a box called a stacking context.

The stacking context is the whole answer

A stacking context is a self-contained painting order. Everything inside one paints together, as a unit, at whatever position its root occupies in the parent context. Nothing inside can paint above something outside it.

Which produces the rule that explains almost every one of these bugs: a child of a context with z-index: 1 sits below a sibling of that context with z-index: 2 - at 9999, at 2147483647, at any number you can type.

the tooltip never wins, and the number is irrelevant

.card    { position: relative; z-index: 1; }
.overlay { position: relative; z-index: 2; }

.card .tooltip { position: absolute; z-index: 9999; }

/* .tooltip paints inside .card, so it paints under .overlay.
   The only number that matters here is the 1. */

The same tooltip at z-index: 9999, twice. The only thing changing is opacity on its parent - and opacity below 1 opens a stacking context, which puts the tooltip under an overlay it used to sit above. - runs on the page itself.

So the element you are editing is rarely the one deciding. The question is which ancestor opened a context, and where that ancestor sits among its own siblings.

It is worth being precise about what a context does to the numbers inside it, because the mental model people carry is usually a bigger number wins rather than the true one, which is closer to a version scheme. 1.9999 is still less than 2. The ancestor is the integer part.

What creates one is a longer list than anybody remembers

The familiar case is a positioned element with a z-index other than auto. The rest is where the surprises live:

opacity

Any value below 1. A hover state at 0.98 opens a context for the whole subtree.

transform

Any value other than none - including translateZ(0), added for the compositor by someone not thinking about paint order at all.

filter, backdrop-filter

Any value. A blur behind a sticky header is the usual arrival route.

mix-blend-mode

Anything other than normal.

isolation: isolate

The only one on this list whose entire purpose is to do it, and therefore the only one that is never a surprise.

contain

paint, layout, strict or content.

will-change

Naming any property above. A hint about performance that changes correctness.

position: fixed

On its own, with no z-index involved at all.

This is why the bug so often arrives with a commit that has nothing to do with layering. A card gets a hover opacity, a section gets a transform, and a dropdown three levels down that worked yesterday is trapped. Nothing about the dropdown changed.

The move that actually finds it

Do not start at the element. Start above it and work down:

1. Walk from the trapped element up to the root, and at every ancestor ask the one question: does this open a stacking context?
2. The first ancestor that does is your ceiling. Nothing below it can ever paint above something outside it.
3. Find where that ceiling sits among its own siblings. That comparison - not the one you were editing - is the one deciding.
4. Fix it there: raise the ceiling, or move the element out from under it, and put the child back to a number a person can read.

Doing that by hand means reading computed styles for eight properties on every ancestor, which is precisely why it turns into raising the number instead. It is worth doing properly once, because the answer is nearly always a single ancestor with a property nobody associates with layering.

The four fixes, worst to best

Raise the number

Works only when the two elements are already in the same context, which is the case you did not have. It is the fix that produced 9999 in the first place - each round of it raises the ceiling nobody found.

Raise the ancestor

Correct, and usually a one-line change: put the z-index on the ceiling instead of on the child. The risk is that the ceiling now beats things it should not, so it moves the problem up a level rather than removing it.

Move the element out

Render the overlay as a sibling of the ceiling rather than a descendant. In a component framework that means a portal, and the reason portals exist is precisely this - not styling, paint order.

Use the top layer

For anything modal, this is the answer, and it is the only one that cannot regress. See below.

There is a fifth thing people try - position: fixed on the trapped element - and it is worth naming because it seems to work. A fixed element escapes scrolling ancestors, not stacking contexts. If any ancestor has a transform, filter or will-change, the fixed element is positioned against that ancestor instead of the viewport, and the bug becomes two bugs.

isolation: isolate, and the one time you want more of this

Everything above treats a stacking context as an accident. isolation: isolate is the property that creates one on purpose, and it is the right tool in one specific situation: a component whose internal layering must not leak into the page it is dropped into.

a component that cannot fight with the page around it

.widget {
  isolation: isolate;
}

/* Everything inside .widget now sorts among itself.
   The page sorts .widget as one thing.
   Nothing inside can reach past it, in either direction. */

That is the same mechanism causing every bug in this article, aimed deliberately. A stacking context is not a hazard; an accidental one is. The difference is whether you knew you were opening it.

The top layer ignores all of it

A <dialog> opened with showModal(), an element with the popover attribute, and anything in fullscreen do not participate in this system at all. They paint in the top layer: above every stacking context on the page, in the order they were opened.

no z-index anywhere, and nothing can cover it

<div popover id="menu">…</div>
<button popovertarget="menu">Open</button>

No z-index competes with the top layer and none is needed on it. Which makes it the real fix for the case that produces 9999 in the first place - a modal, a tooltip, a menu that has to escape whatever it is nested in. Not a bigger number. A different layer.

Sideways scroll is one of the few layout bugs with a single cause. Something is wider than the viewport, or starts far enough right that its edge lands outside it. There is no cascade to reason about and no specificity to lose to. There is one element, and the work is finding it.

It is also the bug most often closed without being found, because hiding it takes one line and looks identical in the screenshot.

The handful of things that actually do it

100vw

On a desktop browser with a classic scrollbar, 100vw is the viewport including the scrollbar; the content box you are comparing it against is not. A full-bleed section overflows by around fifteen pixels - enough to scroll, small enough to read as a rendering fault.

min-width: auto

The default on flex and grid children, and it means do not shrink below your content. A long word, a wide table or an unbroken URL in a grid cell will push the whole track. Responsible for more of these than everything else here combined.

Fixed pixel widths

A width: 480px card in a 390px viewport. Obvious in review, invisible on the desktop it was written on.

Negative margins

A full-bleed trick pulling content out past the right edge, usually correct on one breakpoint and not the others.

Absolute positioning

right: -40px on a decorative shape. The element is out of flow, but not out of the scroll area.

Unbreakable strings

A URL, a hash, a wallet address, a base64 blob. No spaces means no wrap opportunity, unless overflow-wrap: anywhere says otherwise.

Three rows in a frame. Two are sized to the content box; the middle one is sized to 100vw, which on a desktop browser includes the scrollbar the content box does not get. Fifteen pixels, and the page scrolls. - runs on the page itself.

Worth knowing what does not do it: box-shadow and outline paint outside the box without contributing to scroll width. transform: translateX does contribute, even though the layout position has not moved.

Why the outline trick misleads

the advice everybody gives

* { outline: 1px solid red; }

It works often enough to stay in circulation, and it is wrong in a specific way: it marks every element, so the offender and its dozen innocent descendants all appear to stick out together. You end up staring at the deepest one - a <span> inside the thing that is actually too wide - because it is the one whose red box is easiest to see.

It also cannot see anything already clipped by an ancestor with overflow: hidden set for a legitimate reason, which is exactly where these hide.

Measure edges instead

The reliable test is arithmetic, not colour. Compare every element's right edge against the document width, then take the shallowest element that fails:

the whole diagnosis, in five lines

const limit = document.documentElement.clientWidth;

[...document.querySelectorAll('*')]
  .filter((el) => el.getBoundingClientRect().right > limit)
  .slice(0, 5);

// The first result is the cause.
// Everything after it is a passenger inside the cause.

The same pass catches the left side, which people forget exists. An element at a negative offset does not always produce scroll - a browser does not scroll into inline-start overflow in a left-to-right document - but it does in a right-to-left one. Which is how this ships broken in Arabic and Hebrew after passing every check in English.

The two fixes for the two commonest causes

Once the element is identified, the repair is nearly always one of two lines. Neither is clever, and both are worth knowing by heart.

full bleed without the scrollbar arithmetic

.bleed {
  width: 100dvw;
  margin-inline: calc(50% - 50dvw);
}

/* Or skip the unit question entirely: */
.bleed-grid {
  grid-column: 1 / -1;
}

letting a flex or grid child actually shrink

.track > * {
  min-width: 0;
}

.track pre,
.track code {
  overflow-wrap: anywhere;
}

/* min-width: auto is the default and it means
   "never shrink below my content". A table, a long
   URL or a wide <pre> will push the whole track. */

min-width: 0 on flex and grid children is the single highest-value line in responsive CSS, and it is invisible until the day a long word arrives. Some teams set it globally on grid and flex children and never see this class of bug again.

Catching it before a person does

This bug has an unusual property among layout bugs: it is trivially detectable in CI. It is one comparison of two numbers, it needs no screenshots and no visual diffing, and it fails deterministically.

the assertion, at three widths

for (const width of [320, 768, 1280]) {
  await page.setViewportSize({ width, height: 900 });
  const scrolls = await page.evaluate(
    () => document.documentElement.scrollWidth >
          document.documentElement.clientWidth,
  );
  expect(scrolls, `scrolls sideways at ${width}px`).toBe(false);
}

320 is the width WCAG asks a page to reflow to, so that row is a conformance check as well as a layout one. Adding those three lines is usually the last time anybody thinks about horizontal overflow in that codebase.

When hiding it is the correct answer

Sometimes it genuinely is: a decorative shape deliberately drawn past the edge, a carousel whose track is meant to be wider than its frame. In both cases the clip belongs on that element or its immediate container - never on body or html.

The reason is not tidiness. overflow on the scroll container is what makes position: sticky stop working, and the failure surfaces somewhere else entirely, weeks later, as a header that will not stick. A clip scoped to the thing being clipped costs nothing and takes nothing else down with it.

If you inherit a codebase with overflow-x: hidden on body, remove it before debugging anything sticky. You are not looking for a sticky bug. You are looking for the overflow it was hiding.