In CSS, if an img has only its width set and height left at the default auto, what height does it render at and why?

## Replaced elements and intrinsic size Most boxes on a page are sized by CSS and by the content flowing inside them. A **replaced element** is different: its rendering is not described by the document's own content but by an external resource — an image file, a video stream, a plugin surface. `img`, `video`, `canvas`, `iframe`, `embed` and `object` are the common ones. Because the resource exists independently of the page, it can bring its own dimensions with it. The spec calls these **intrinsic sizes**, and a box can have up to three: - an **intrinsic width** (a 800px-wide bitmap), - an **intrinsic height** (600px), - an **intrinsic aspect ratio** (4:3). A raster image has all three. An SVG without `width`/`height` attributes but with a `viewBox` typically has only the ratio. A `canvas` or `iframe` has none of them from the resource itself. ## How auto resolves The default `width` and `height` of a replaced element are both `auto`, and the sizing algorithm fills the gaps in a fixed order: - **Both auto** — use the intrinsic width and height (the image renders at its natural pixel size). - **One auto, one specified** — compute the auto one from the specified one through the intrinsic ratio. - **Neither auto** — use both as given; the ratio is simply not consulted. So this: ```css img { width: 400px; height: auto; } ``` with an 800x600 source produces a used height of 300px. Halve the width, halve the height. This is why `height: auto` is the value you want on responsive images, and why `img { max-width: 100%; height: auto; }` is a decades-old staple: the max-width caps the image inside a narrow container and the auto height keeps it from squashing. When no intrinsic size and no ratio is available and CSS says nothing either, the box falls back to a **default object size** of 300px by 150px. That is where the mysterious 300x150 `iframe` or `canvas` comes from. ## Distortion when you fix both axes Setting both dimensions to values that contradict the ratio does not letterbox anything. The initial value of `object-fit` is `fill`, meaning the resource is stretched to exactly fill the content box: ```css .avatar { width: 100px; height: 100px; object-fit: cover; object-position: center; } ``` `cover` scales the image until it covers the box and crops the overflow; `contain` scales it until it fits entirely, leaving empty space. `object-position` chooses which part survives a `cover` crop. These properties act on the *replaced content inside* the box — they never change the box's own size, which CSS has already decided. ## The width and height attributes Before the file arrives, the browser has no intrinsic size to work with, so a bare `img` occupies no space and then jolts the page when the bytes land. Current engines (Chrome 79+, Firefox 71+, Safari 14+) solve this by deriving a default aspect ratio from the HTML `width` and `height` attributes, roughly as if the UA stylesheet said `aspect-ratio: attr(width) / attr(height)`. Combined with `height: auto` in your CSS, the browser can compute the correct display height from the CSS width immediately and hold the space open. That is why the modern advice is to keep both attributes on the markup *and* still write `height: auto` in CSS — the attributes supply the ratio, the CSS supplies the responsive width, and the auto height ties them together. ## What interviewers are checking The question separates people who think `width` and `height` are two independent knobs from people who know a replaced box has a size of its own that CSS merely constrains. The follow-through — distortion when both are pinned, the 300x150 fallback, the pre-load ratio — is all one idea: the resource has an opinion about its size, and `auto` is how you defer to it.