`frame-sizing` lands in Chrome 154

Chrome 154 lets an <iframe> derive a dimension from its embedded document’s intrinsic size when both documents opt in. Chrome for Developers described the feature on 2026-09-16. The embedding document uses the CSS frame-sizing property, the embedded document uses the responsive-embedded-sizing meta value, and window.requestResize() requests another calculation after content changes (Responsive iframes in Chrome 154).

Consent from both documents

An iframe ordinarily owns a viewport. When its embedded document is taller than that viewport, the frame can show a scrollbar rather than expanding to contain the document. The CSSWG explainer describes responsive iframe sizing as a way to add content-based layout while retaining the document isolation offered by same-origin and cross-origin frames. It requires action from both the page that embeds the frame and the document inside it (CSSWG responsive iframe explainer).

The embedding page applies frame-sizing to the iframe element. Chrome’s article lists auto, content-width, content-height, content-inline-size, and content-block-size. auto preserves existing iframe sizing. The content values select the physical or logical dimension that comes from the embedded document, while other CSS constraints on the iframe can still participate in layout (Responsive iframes in Chrome 154).

The embedded document opts in with a meta element whose name is responsive-embedded-sizing. MDN describes this value as permission to share the document’s layout size with its parent so that frame-sizing can use it. Chrome’s article adds that the meta element must be present when the document loads and cannot be inserted dynamically afterward to activate the feature (MDN, responsive-embedded-sizing).

This double opt-in distinguishes control of the element from consent by the framed document. The CSSWG explainer says the design preserves backward compatibility for existing content and the privacy and security properties expected of cross-origin content. Without the matching choices, an existing iframe keeps its established sizing behavior instead of exposing its content dimensions to its embedder (CSSWG responsive iframe explainer).

The embedded document can restrict which parent origins receive its size. Chrome’s example uses allow-origins= inside the meta content value and shows a single origin or multiple space-separated origins. It advises third-party widgets to name only the origins that need access. A wildcard permits every embedding origin, while an explicit list makes the sizing disclosure narrower (Responsive iframes in Chrome 154).

That origin list does not replace existing embedding controls. Chrome’s article describes it as complementary to the CSP frame-ancestors directive, which governs which sites may embed the document. The CSSWG explainer likewise discusses frame-ancestors as a mitigation when a malicious embedding document could otherwise observe a cross-origin frame’s laid-out size (Responsive iframes in Chrome 154).

Initial size and later changes

The initial size exchange is tied to document loading. The CSSWG explainer says that when the opt-in meta element is present at the embedded document’s load event, the embedding document is notified of a natural dimension. The iframe’s frame-sizing value then lets that dimension participate with the other HTML and CSS constraints applied by the embedding document (CSSWG responsive iframe explainer).

Later layout changes do not trigger continuous observation. Chrome’s article says the browser does not observe every layout change in the embedded document. After adding content, expanding a panel, or otherwise changing layout, code inside the frame can call window.requestResize() to request a new size calculation. MDN describes the same method as the dynamic update path after the embedded document changes (Responsive iframes in Chrome 154).

Chrome recommends completing document changes and calling requestResize() before layout. Its explanation connects this explicit update model to avoiding resize loops: a new frame size can change the embedded viewport, which can change content layout and then change the requested size again. The method is therefore an application-controlled request, not a general-purpose observer that tracks every mutation (Responsive iframes in Chrome 154).

The CSSWG explainer records why the initial design used one-shot sizing. It lists changing frame size, cumulative layout shift, performance costs, and potential infinite layout loops among the concerns behind calculating the natural size at load rather than reacting automatically to all later content and style changes. Its future-extension section describes a JavaScript relayout request as a possible addition; Chrome 154’s published feature includes requestResize() for that explicit role (CSSWG responsive iframe explainer).

Significance for iframe layout

Embedded forms, comments, and worked examples can change height without belonging to the same document as the application shell. Chrome’s article says the older pattern requires code to measure iframe content, communicate dimensions through postMessage(), and update the iframe in the parent. The new contract puts the initial dimension exchange in CSS and document metadata, while retaining an explicit method for later updates (Responsive iframes in Chrome 154).

The change does not remove the need to design fallback sizing. Chrome documents an @supports (frame-sizing: content-height) pattern that keeps a fixed height outside the feature query and replaces it with content-based sizing when supported. It also shows feature detection for requestResize before calling the method. Existing iframe sizing code can remain available for user agents that do not implement the feature (Responsive iframes in Chrome 154).

The original report records Chrome 154 support and links open browser bugs for Firefox and Safari. MDN labels responsive-embedded-sizing experimental and not Baseline because it does not work in some widely used browsers. Those sources support progressive enhancement, not replacement of every established iframe technique with an unconditional new property (New in Chrome 154).

Layout stability remains a product concern even in a supporting browser. Chrome warns that a frame may shift surrounding content when its embedded document loads after the host document. It specifically says this can negatively affect Core Web Vitals when a responsive iframe appears in the first viewport. Applying a maximum height or reserving space can change that trade-off, but the appropriate constraint depends on the embedded content (Responsive iframes in Chrome 154).

The feature also makes ownership explicit. The embedder chooses whether a frame dimension should derive from content and retains its own CSS constraints. The embedded document chooses whether to disclose size and can limit eligible parent origins. Code inside the frame chooses when later changes deserve a new calculation. Treating these as separate decisions avoids assuming that control of an <iframe> element implies control of the document it loads (MDN, responsive-embedded-sizing).

A rollout can therefore preserve a known height, add frame-sizing inside a feature query, include the opt-in in the embedded document at load time, and guard calls to requestResize(). That sequence follows Chrome’s progressive-enhancement examples and keeps unsupported user agents on the existing path. It also gives the team a place to measure layout movement before using content sizing in a visually prominent region (Responsive iframes in Chrome 154).

Security review should cover both the right to embed and the right to receive dimensions. An explicit allow-origins list controls the latter, while frame-ancestors controls the former. The CSSWG explainer warns that observable cross-origin dimensions can reveal information about framed content, which is why the embedded document’s opt-in and origin restriction are substantive parts of the design that protect cross-origin information (CSSWG responsive iframe explainer).

The practical change in Chrome 154 is narrow: supported frames gain a standardized-looking content-sizing path with explicit consent and updates. It does not make an iframe’s DOM available to its parent, turn later layout changes into automatic notifications, or remove the need for cross-browser fallbacks. Those boundaries are what make the feature suitable for incremental use rather than an all-or-nothing rewrite (Responsive iframes in Chrome 154).

Related entries

• Platforms: see platform model and terminology.
• Baseline 2026: see record of the 2026 Baseline set.
• By browser: see browsing OpenPWA compatibility data by browser.

Open and unverified

• The release versions in which Firefox or Safari might support responsive iframe sizing are not confirmed.
• Whether the property, meta value, or method changes before broader interoperability is not confirmed.
• The layout-shift effect for a particular PWA, iframe, and reserved-space strategy is not confirmed without measurement.
• The appropriate allow-origins list for a third-party widget depends on its deployment relationships and is not confirmed.
• Whether nested responsive frames receive additional implementation limits is not confirmed.
• When this feature might satisfy the Baseline criteria is not confirmed.

Sources

• New in Chrome 154: iframes that automatically resize themselves to their content (bram.us)
• Responsive iframes in Chrome 154 (developer.chrome.com)
• Responsive iframes explainer (github.com)
• responsive-embedded-sizing meta value (developer.mozilla.org)