HTML requires the id attribute to be unique within a document. What actually breaks when two elements end up with the same id?

## What the rule actually says The `id` attribute is global — legal on every element — and its value must be **unique within the whole document**. Two more rules are easy to forget: the value must not be the empty string, and it must not contain ASCII whitespace. Beyond that almost anything is allowed, including a leading digit and punctuation, although such ids need escaping when written into a selector. Uniqueness is a *conformance* requirement. A conformance checker reports duplicates as an error; a browser does not. There is no exception, no console warning, no visual difference. That silence is the whole reason this question gets asked. ## The split that causes the bug The DOM has two families of id consumers, and they behave differently on duplicates. **Single-element resolution takes the first match in tree order:** ```html <input id="total" value="a"> <input id="total" value="b"> <label for="total">Total</label> ``` ```js document.getElementById("total").value; // "a" — the second input is unreachable this way ``` Everything in this family follows the same rule: - `document.getElementById(id)` - fragment navigation to `#id`, whether by URL or by an in-page link - `<label for="id">`, which binds to the first labelable element with that id - ID-reference attributes: `aria-labelledby`, `aria-describedby`, `aria-controls`, an input's `list="…"` pointing at a `<datalist>`, and a control's `form="…"` pointing at a `<form>` it sits outside of **Selector matching ignores uniqueness entirely:** ```js document.querySelectorAll("#total").length; // 2 ``` A selector is just an attribute test, so it happily matches every element carrying that id, and a style rule keyed on the id paints all of them. ## Why this is worse than it sounds The two behaviours combine into a bug that looks like it works. Presentation is driven by selectors, so the page renders exactly as designed. Behaviour is driven by single-element resolution, so it quietly attaches to the wrong node. Concretely: - Clicking the visible label focuses or toggles the *other* control, often one scrolled off-screen. - A screen reader computing an accessible name from `aria-labelledby` reads the first matching element's text, so a duplicated widget announces the wrong thing for every instance but the first. - A share link to `#pricing` scrolls to whichever `#pricing` came first in the document. - Test selectors written against the id become order-dependent and flaky. ## Where duplicates come from Almost always from a reusable chunk of markup with an id baked into it — a form partial, a component template, an icon sprite copied twice, an accordion panel included on a page that already has one. Rendering it twice is the whole failure mode. Related: an element whose id changes over the life of the page can leave stale ID references pointing at nothing, which is a different bug with the same smell. ## Getting it right - Give each instance a unique token and build ids from it, so one component renders `field-3-email` rather than `email`. - Reserve `id` for the cases that genuinely need a document-wide address: label association, ARIA references, fragment targets, `form` and `list` wiring. Use classes or `data-*` attributes for hooks that only need to identify a kind of thing. - Run a conformance check or an accessibility audit in CI; duplicate-id is one of the errors both catch reliably and cheaply. If you ever need every element carrying an id-shaped value, that is a sign the value is describing a category rather than an address — a class or data attribute is the right tool.