Why should an HTML <img> carry width and height attributes even when CSS controls its rendered size, and what does the browser do with those two numbers?
answer
- the file's real size, not the rendered size
- layout happens before the bytes arrive
- two numbers become a ratio
- reserve the box, avoid the jump
- CSS still wins on rendered size
basics
~20 sThe width and height attributes give the browser the image's aspect ratio before the file arrives, so it can reserve a correctly proportioned box during the first layout instead of collapsing the space and shoving content down when the image lands.
solid answer
~50 sSet the image's **intrinsic** pixel dimensions in the `width` and `height` attributes on every `<img>`. Current browsers apply a default `aspect-ratio` derived from those two numbers, so the very first layout — before any image bytes have arrived — reserves a box of the right shape. Without them the browser has nothing to go on: it lays out a zero- or default-height box and then resizes it when the file downloads, pushing everything below it down the page. That jump is the layout shift users experience as text moving while they read. CSS still owns the rendered size; the attributes are a ratio, not a lock, so a rule like `width: 100%` with `height: auto` scales the image while preserving the reserved proportions. The numbers must match the actual file, though — wrong ones reserve the wrong shape.
code
html · 2 lines<!-- Intrinsic pixel size of the file, no units -->
<img src="/img/cover.jpg" width="1600" height="900" alt="Harbour at dusk">go deeper
Be able to say that width and height hold the image file's real pixel dimensions and that their job is to reserve space so the page does not jump when the image loads.
Explain the mechanism: browsers derive a default aspect ratio from the two attributes, so the first layout — which happens before any image bytes arrive — can size the box correctly, while CSS still controls the rendered dimensions.
Demonstrate that you would hunt this down systematically: find unsized images across templates and components, require dimensions at the component boundary, and verify the shift is gone rather than assuming the attribute fixed it.
Own it as a pipeline concern — dimensions emitted automatically from the asset store or build step so no author can ship an unsized image, and a policy for user-uploaded media whose size must be captured at ingest.
## The problem being solved An image's real dimensions live inside the image file. The browser learns them only after enough of the file has downloaded to read its header. But layout happens long before that: the parser reaches the `<img>`, needs to know how much room the element takes, and — with no information — treats it as an empty inline box. So the page is laid out once with the image occupying almost nothing, and again when the image arrives and suddenly demands, say, 600 pixels of height. Everything below it jumps down. The user was mid-sentence, or mid-tap on a button that has now moved. ## What the attributes do ```html <img src="/img/portrait.jpg" width="800" height="1200" alt="…"> ``` These are the image's **intrinsic** dimensions — the pixel size of the actual file — written as bare numbers, with no units and no `px` suffix. Current browsers apply a default style equivalent to `aspect-ratio: attr(width) / attr(height)` to images that carry both, which means the two numbers are consumed as a *ratio* rather than as a fixed size. The first layout can therefore reserve a box of the right shape immediately, and the image drops into a hole that was already the right shape. This is why the old advice "don't put width/height in HTML, that's CSS's job" is now wrong. It made sense when the attributes acted only as a hard size and fought with responsive CSS. Today they are the input to the aspect-ratio calculation, and omitting them throws that information away. ## How they coexist with CSS CSS still decides the rendered size — it wins over the presentational attributes. The common responsive pattern is a fluid width with an automatic height, which lets the reserved ratio do its job at whatever width the container ends up: the box is as wide as the layout allows and as tall as the ratio implies. If a stylesheet pins a height explicitly, the ratio is overridden and you are back to whatever that rule says. The practical failure mode here is a stylesheet that sets only `width: 100%` and leaves the height alone in a way that reintroduces the jump. If images still shift after you have added the attributes, the stylesheet is the next place to look — but the markup fix comes first, because without the attributes no amount of CSS can know the ratio. ## Getting the numbers right - Use the file's true pixel dimensions. If the served file is 1600×900, write `width="1600" height="900"`, even when it renders 400 pixels wide. - Keep them in sync when the asset is replaced. A swapped image with stale attributes reserves the wrong shape, which is its own visual bug — the space is held, then the image reflows into a different one. - What is used is the *ratio*, so `1600×900` and `800×450` reserve the same shape. - If a single `<img>` serves candidate files at several sizes, they should share one aspect ratio; the attributes describe that shared shape. ## Why this pairs with deferred loading An image that is fetched late — because it is far down the page and deliberately deferred — is precisely the one whose arrival will interrupt a reader mid-scroll. Reserving its space is not optional. The two habits go together: defer what is off screen, and always reserve the box so the deferral is invisible rather than disruptive. ## What good looks like in review Every `<img>` in the codebase has both attributes, they are generated from the asset rather than typed by hand where possible, and a component that takes an image as a prop requires its dimensions rather than defaulting them. An image element with neither attribute should read, to a reviewer, the same way a missing `alt` reads: a defect with a known consequence, not a style preference.
- If CSS overrides the rendered size anyway, in what sense are the attributes used at all?They are consumed as a ratio, not as a size. Browsers apply a default `aspect-ratio` computed from the two attributes, so a fluid `width` with an automatic height still reserves a correctly proportioned box on the first layout. CSS decides how big; the attributes decide what shape, before the file exists.
- What happens if the attributes do not match the actual image file?The browser reserves a box of the wrong shape, then reflows to the real proportions when the file arrives — you get a layout shift anyway, sometimes a worse-looking one because the wrong space was held first. Generate the values from the asset rather than typing them, and update them whenever the file is replaced.
- Does this advice apply to an image whose size is genuinely unknown at author time, such as a user upload?Yes, but you have to capture the dimensions when the file is stored and emit them with the markup. If they truly are unknowable, reserve space another way — a wrapper with a fixed ratio — rather than shipping an unsized `<img>`. Unknown size is a data-pipeline gap, not a reason to omit the attributes.
saying these in an interview costs you the question
- Says width and height in HTML are obsolete and belong only in CSS
- Writes the rendered CSS size in the attributes instead of the file's real size
- Adds px units or percentages to the attribute values
- Thinks the attributes lock the size so CSS cannot resize the image
- Sets only one of the two and expects a reserved box