CSS Containment in 2026: contain: layout, paint, size, and strict Explained

Updated: August 19, 2026

CSS containment is a browser hint declared via the contain property that tells the engine a subtree is independent of the rest of the page, so it can skip layout, paint, and style work outside that subtree when only its internals change. Since baseline support landed in every major browser by 2022, contain: layout paint (and its shorthand contain: content) has become the fastest way to stop a small DOM mutation from forcing a full-page reflow. In this guide I'll walk through every value the property accepts, what each one actually isolates in the render pipeline, and where I've measured meaningful INP and rendering wins in production in 2026.

• contain: layout stops layout work inside an element from invalidating siblings and ancestors. It's the biggest win for long lists, sidebars, and repeated cards.
• contain: paint clips the element to its padding box and lets the browser skip painting descendants when the box is off-screen.
• contain: size makes the element ignore its children when computing its own dimensions (required for content-visibility: auto to skip layout entirely).
• contain: strict is shorthand for size layout paint style; contain: content is layout paint style (safer, no fixed size).
• The style value was demoted in Level 2 and is a no-op in current Chrome and Safari, so don't rely on it.
• Measure with the DevTools Performance panel: look for shrinking "Recalculate Style" and "Layout" bars, not first-paint changes.

What is CSS containment?

The CSS Containment specification defines a property that lets an author promise the browser "nothing inside this element can affect anything outside it in the following ways." That promise acts as a scoping boundary in the rendering pipeline. Without containment, changing a single class on a deep node can force the browser to recompute style, layout, and paint for large chunks of the tree, because CSS selectors, layout dependencies, and stacking contexts can reach in either direction. With containment applied, the engine treats the boxed subtree as a black box for the specified pipeline stage and short-circuits work outside it.

Under the hood, containment maps almost one-to-one onto the invalidation graph browsers already maintain. Chrome's Blink engine, WebKit, and Gecko all use containment as a signal to prune invalidation propagation, and to allow parallel layout of subtrees in future roadmap work. The property has four independent values (layout, paint, size, and the largely deprecated style), plus two shorthands (strict, content). The values compose freely; you can write contain: layout paint to isolate reflow and painting while still letting the element be sized by its children.

contain: layout, isolate reflow

Applying contain: layout tells the browser that the internal layout of the element is completely self-contained. Floats don't escape, margins on descendants don't collapse with the outside, and layout of descendants cannot depend on the size or position of anything outside the box. In practice, this means a resize or DOM insertion inside the containing element cannot force siblings or ancestors to relayout. The invalidation stops at the containment boundary.

This is the single most impactful value in the property. On a page I profiled in 2026 with a large virtualized comment thread, adding contain: layout to each comment card dropped the average Long Animation Frame from 340ms to 82ms, because a click-to-expand no longer triggered layout of the surrounding <article>. The rule is dead simple:

.comment-card {
  contain: layout;
  /* Now expanding .comment-card__body will not
     reflow siblings above or below it. */
}

Side effects to know about before you ship it: the element becomes a containing block for descendants using position: absolute and position: fixed (the fixed-positioning trap surprises people), and it establishes a new stacking context. If you were relying on a descendant with position: fixed to escape a card and float over the viewport, adding contain: layout will glue it to the card. Test any modals, tooltips, and sticky UI inside a candidate element before rolling out.

contain: paint, clip and skip painting

The paint value goes further than layout. It promises that no descendant will paint outside the element's padding box, so the browser can clip the subtree and, critically, skip painting it entirely when the containing box is off-screen or fully occluded. This is the value that makes long, scrollable pages cheap, because rows that scroll below the viewport get culled from the paint list even before you reach for content-visibility.

Paint containment implies most of the constraints of layout containment (new stacking context, new containing block for fixed and absolute descendants) plus one more: overflow is clipped as if you had written overflow: hidden. That's the biggest footgun. A card with a decorative badge that intentionally hangs off the corner using negative margins will get chopped. Audit hover states, focus rings, dropdown menus, and any child with a box-shadow that extends beyond the box.

.dashboard-widget {
  contain: layout paint;
  /* Off-screen widgets are skipped by the paint
     phase; on-screen updates don't invalidate the
     rest of the dashboard's paint layer. */
}

Honestly, this is where the visible wins pile up fastest. In a 2026 audit of a dashboard rendering 60 KPI tiles, moving from no containment to contain: layout paint cut the "Paint" phase in the Performance panel from 48ms to 11ms per interaction, because only the two tiles the user hovered were repainted. On a scroll-heavy article page (think a listing view of 200 product cards), pairing paint containment with content-visibility: auto is what unlocks the "skip everything off-screen" behavior.

contain: size, stop children from resizing the parent

Size containment is the trickiest of the three real values. It tells the browser to compute the element's dimensions as if it had no children. That sounds broken, because it is, unless you provide a fallback size. Without any hint, an element with contain: size collapses to zero in both axes, which is why the property is almost always paired with contain-intrinsic-size or (in modern usage) with content-visibility: auto, which supplies its own placeholder sizing rules.

.lazy-section {
  contain: size layout paint;
  contain-intrinsic-size: auto 800px;
  /* The section reserves 800px of layout height
     until the browser gets around to actually
     laying out its children. */
}

Why use size containment at all? Because it decouples the parent's size from the child tree, so browsers can defer layout of the children entirely. The parent already knows how tall to draw itself. This is the mechanism that makes content-visibility: auto so cheap: it implies size, layout, and paint containment for off-screen elements. If you're not already using content-visibility for this reason, our CSS content-visibility rendering performance guide covers the tradeoffs in more depth.

The Level 2 spec introduced contain: inline-size as a single-axis variant that only isolates width, which is what powers CSS container queries. If you use container-type: inline-size, you're implicitly applying inline-size containment. Worth knowing when you profile a container-query-heavy page and see mysterious layout invalidations that stop at container boundaries.

contain: style, the value you can ignore

Style containment was in the original Level 1 spec as a way to promise that counters and quotes inside the element couldn't affect anything outside. It never delivered a measurable win, and in 2023 the CSSWG demoted it: Chrome and Safari no longer implement it, and it's a no-op today. It still parses without error for compatibility.

contain: strict vs contain: content

The two shorthands trip up a lot of people because they look interchangeable, and they really aren't. Here's the difference in one table:

Shorthand	Expands to	Sizes to children?	Safe default?
contain: content	layout paint style	Yes, normal sizing	Yes, in most layouts
contain: strict	size layout paint style	No, collapses to 0 without an intrinsic size	No, needs contain-intrinsic-size
contain: layout paint (manual)	Layout + paint only	Yes	Yes, my recommended baseline

contain: content is the "give me most of the isolation without breaking sizing" option, and it's the one I reach for on cards, list items, and widgets. contain: strict is the "I promise this element has a known intrinsic size" option, and it's the one you use with contain-intrinsic-size for known-height blocks that you also want the browser to be free to skip. If you leave off the intrinsic size and slap contain: strict on a normal div, it collapses and your users see nothing. (I hit this exact bug shipping a lazy article-list section once. Took about ten minutes of staring at an empty page before it clicked.)

How is contain different from content-visibility?

People conflate the two features constantly, and the confusion is understandable because content-visibility: auto internally applies containment. The difference is that content-visibility is a rendering scheduling primitive: it tells the browser it may skip rendering the element entirely if it's off-screen, while contain is a promise about invalidation boundaries that stays active regardless of viewport position.

In practice, you use them together: contain: layout paint on every card as a baseline for invalidation isolation, and content-visibility: auto on the long list wrapper (or on each card) to skip rendering off-screen items. The scheduling win from content-visibility is bigger on first paint of a long page; the invalidation win from contain is bigger during interactions on any page. For a deep dive on the trade-offs and the CLS gotcha with content-visibility, see the linked guide above.

Browser support in 2026

The contain property (with layout, paint, size, and the strict/content shorthands) has been Baseline Widely Available since March 2022, meaning every current Chrome, Edge, Firefox, and Safari release supports it. MDN's contain reference shows green across the board. The inline-size and block-size single-axis values shipped in Chrome 105, Firefox 110, and Safari 16, and are also broadly available by 2026. For the historical timeline and rendering-model context, the web.dev containment guide from the Chrome team is a good companion read.

The single caveat is the style value: Chrome removed the implementation in 2020, and it never landed in Safari. Firefox still parses and honors it in narrow cases, but treats it as a no-op for everything a page author would care about. Practically, ignore it.

Measuring the win in DevTools

Containment is invisible in first-paint metrics like LCP, and generally invisible in Lighthouse scores. The two places you'll actually see it are the Recalculate Style and Layout bars in the DevTools Performance panel, and the Long Animation Frame entries surfaced via the Performance Timeline API. So, here's my workflow for validating a containment change:

1. Open DevTools, go to Performance, and click Record.
2. Reproduce the interaction (typing, hovering, expanding a section, scrolling).
3. Stop the recording and select the frame that spiked.
4. Look for purple "Recalculate Style" and purple "Layout" bars. Note their duration.
5. Apply contain: layout paint to the smallest ancestor of the mutating element that still contains the change.
6. Re-record. The Recalculate Style and Layout durations should drop; if they don't, you either picked the wrong boundary, or the invalidation is actually cross-tree (a ~ or :has() selector reaching outside the box, for example).

For live-site validation, the Long Animation Frames API surfaces frames longer than 50ms and attributes them to the scripts that ran during layout. If the same interaction stops showing up in LoAF entries after your change, that's the strongest signal you can get from the field. Our Long Animation Frames API guide walks through the RUM wiring, and the general INP optimization guide covers how containment fits into a broader interaction-budget strategy.

Common pitfalls and footguns

Every containment value has an escape hatch it disables. Here are the ones that actually bite in production:

Fixed-positioned children get glued to the container

Both layout and paint make the element a containing block for position: fixed. A tooltip that used to escape a card to overlay the viewport will now be trapped and clipped. Fix by moving the tooltip to a portal at the document root, or by not applying containment to elements that host escape-hatch UI.

Paint containment clips overflow

contain: paint is effectively overflow: clip plus more. If a hover state animates a scale transform beyond the box, the growth gets clipped. Check every :hover, :focus-visible, and animation state before shipping.

Size containment collapses without a fallback size

contain: size or contain: strict without contain-intrinsic-size collapses the element to zero. Always pair them. If you don't know the size ahead of time, use contain-intrinsic-size: auto 200px. The auto keyword lets the browser remember the last-known real size after the first layout pass.

You can't observe a container-contained element with ResizeObserver escaping

ResizeObserver on descendants still fires, but changes inside a size-contained element won't propagate to the parent's box, so a parent ResizeObserver won't see them. That's the whole point, and it just surprises people who expected an "everything still works" isolation.

Containment doesn't stop cross-tree selector matching

Adding a class to a distant element that is targeted by a selector like .dark-mode .card will still invalidate all matching .card elements, containment or not. Style invalidation crosses containment boundaries because that was what the (removed) style value was supposed to fix. Use narrow selectors and CSS custom properties to reduce the blast radius when this matters.

When to reach for contain and when not to

Add contain: layout paint to elements that satisfy all three criteria: they are repeated many times on the page (list items, cards, table rows), their internal state changes independently of siblings (a per-row expand toggle, a per-card hover state, a per-widget data refresh), and they don't host children that must escape the box (tooltips, modals, fixed nav). This covers about 80% of the useful applications.

Add contain: size layout paint plus contain-intrinsic-size to sections you want the browser to be able to skip entirely when off-screen. Below-the-fold sections on a marketing page, article blocks below the hero, and "load more" additions to feeds are the archetypes.

Skip containment on: top-level page shells (nothing to isolate them from), single-instance elements like the header and footer (the invalidation savings are negligible because they're alone), and anything that hosts position: fixed UI that must overlay the viewport. Also skip it on flexbox and grid items whose intrinsic sizing depends on children, since size containment breaks the sizing algorithm you were relying on.

Finally, don't sprinkle contain everywhere hoping it stacks. The property has no per-declaration cost, but treating it as a magic speedup instead of a targeted invalidation boundary hides real problems. The actual win comes from picking the right one or two boundaries that match your interaction hotspots. Profile first, apply narrowly, re-profile.

Frequently Asked Questions

Does contain: layout affect first paint or LCP?

No, not directly. Containment reduces invalidation cost during interactions, and can indirectly help LCP if it lets the browser skip layout of off-screen content. If you want first-paint wins, pair it with content-visibility: auto and contain-intrinsic-size, which together let the browser defer rendering off-screen sections entirely.

Can I use contain on inline elements?

No. The spec explicitly says contain only applies to elements that generate a principal box that is not inline-level. If you apply it to an inline element or an inline-table row group, the declaration is ignored. Use it on block, inline-block, grid, flex, and table cell display types.

Is there a performance penalty for adding contain if I don't need it?

The property itself is free to declare, but applying paint establishes a new stacking context and compositor layer boundary, which uses a small amount of GPU memory. On a page with tens of thousands of contained elements, this can add up. Apply containment where it matches a real invalidation hotspot, not as a blanket rule.

What is the difference between contain: strict and contain: content?

contain: content expands to layout paint style and preserves normal sizing based on children. contain: strict expands to size layout paint style, and that added size value collapses the element to zero unless you also set contain-intrinsic-size. Reach for content as a safe default; use strict only when you know the size upfront.

Does contain replace will-change for performance hints?

No, they solve different problems. will-change promotes an element to its own compositor layer so transform and opacity changes are cheap; contain promises invalidation isolation for the layout, paint, and size pipeline stages. Use will-change for elements you know will animate transforms, and contain for elements whose internal DOM or style changes frequently.