contain: paint

Both clip. Drop a too-wide row of pills into a card with overflow: hidden and the overflow disappears. Swap it for contain: paint and you get the same visual result. So why does the second one exist?

Both cards hide the off-card tag identically. The split shows up when you press the button: overflow: hidden silently turned that card into a scroll container, so setting scrollLeft on it works - the content shifts left and the tag slides into view. contain: paint doesn't create a scroll container at all, so the same assignment is ignored and nothing moves.

That hidden scroll container is the gotcha. A keyboard user tabbing into a focusable child that's been clipped away triggers the same auto-scroll, mid-page, with no scrollbar to suggest it ever could. It also means the browser has to keep treating the box as scrollable: tracking scroll position, considering it a scroll target, dispatching wheel events.

/* Scroll container that happens to hide its scrollbar. */
overflow: hidden;

/* Promise to the browser: nothing paints outside this box. */
contain: paint;

contain: paint is the more honest tool when clipping is all you want. It promises the browser that nothing inside the element will paint outside it, which unlocks real performance shortcuts - the engine can skip the element's subtree when the box is offscreen, and limit invalidation when something inside changes. It also establishes a stacking context and a containing block for absolute and fixed descendants, which is usually what you already wanted from the wrapper anyway.

Reach for overflow: hidden when you actually need a scroll container (and just want the scrollbars gone). For everything else - cards, masked images, rounded corners over child content - contain: paint says what you mean.