In next/image, when do you reach for the `fill` prop instead of width and height, what must be true of the parent element, and why does a `fill` image usually also need a `sizes` prop?

## Two ways to tell Next how big the box is `next/image` must reserve layout space before the file arrives. There are exactly two ways to give it what it needs: 1. **`width` and `height`** — you state the intrinsic dimensions, Next derives the aspect ratio and emits sizing styles. The element keeps its ratio while CSS scales it. 2. **`fill`** — you state nothing, and Next absolutely positions the image to fill whatever box its parent already defines. ```jsx <div style={{ position: 'relative', height: 200 }}> <Image src={photo.url} alt={photo.alt} fill sizes="(max-width: 768px) 100vw, 300px" style={{ objectFit: 'cover' }} /> </div> ``` ## When `fill` is the right choice Reach for it when the *source* dimensions are unknown at author time but the *box* is known from CSS: user-uploaded or CMS images, avatars in a fixed circle, cards in a grid, a hero band that is always 40vh. Reach for `width`/`height` when you do know the intrinsic size — especially for a static import, where Next reads the dimensions from the file for you and you should not be using `fill` at all. ## The parent contract Because the image is absolutely positioned, it is laid out against its **nearest positioned ancestor**. Two things must hold: - that ancestor is positioned (`relative` is the usual choice); - that ancestor has a height that does not depend on the image. The second one is where the common bug lives. An absolutely positioned child contributes nothing to its parent's height, so a `<div style={{ position: 'relative' }}>` with no height wrapping a `fill` image renders a zero-height container and an invisible image. If the parent is not positioned at all, the image escapes further up the tree and stretches across some ancestor you did not intend — usually the whole page. Since the image no longer has an aspect-ratio box, it will stretch to the container's shape unless you say otherwise. `object-fit: cover` (crop to fill) or `object-fit: contain` (letterbox) is effectively part of the pattern, along with `overflow: hidden` on the parent if you are cropping. ## Why `sizes` matters more here than anywhere else The `srcset` Next generates is a menu of widths. The browser picks from that menu using the layout width of the element, its device pixel ratio, and the `sizes` attribute. With `width`/`height` and no `sizes`, Next can emit a fixed-size srcset (1x/2x) around the declared width, which is usually fine. With `fill`, there is no declared width, and the element is out of flow, so the browser has to choose a candidate *before* layout tells it anything useful. Next's fallback is `sizes="100vw"`, which is a claim that the image spans the whole viewport. On a 1440px desktop with a 2x screen, that pushes the browser toward the largest candidate available — for an image that renders in a 300px card. Users pay in bytes and in decode time, and the page often gets a worse LCP than a plain `<img>` would have. A correct `sizes` is just a media-query list describing the element's rendered width per breakpoint: ```jsx sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 300px" ``` Read it as: below 640px this image is the full viewport width; below 1024px it is half; otherwise it is 300 CSS pixels. Providing `sizes` also tells Next to generate candidates across the full configured width range rather than a narrow fixed-size pair, so the browser has genuinely useful options to choose from. ## How this goes wrong in review - `sizes="100vw"` copy-pasted onto a thumbnail grid. It is syntactically fine and silently downloads the largest variant for every tile. - `fill` used on a statically imported asset whose dimensions were already known — you gave up the free aspect ratio for nothing. - A parent with `position: relative` but height driven by its (absolutely positioned) child, producing an empty box. - `sizes` describing the intended design rather than what the CSS actually does; it is a hint the browser trusts, and a wrong hint is worse than a rough-but-honest one. The one-line rule: `fill` delegates the box to CSS, and once CSS owns the box, `sizes` is how you tell the browser what CSS decided.