# `frame-sizing` lands in Chrome 154

> Chrome 154 adds opt-in iframe sizing from embedded content, with explicit updates, origin controls, fallbacks, and layout trade-offs.

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](https://developer.chrome.com/blog/responsive-iframes)).

<span id="the-two-sided-sizing-contract"></span>

## 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](https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md)).

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](https://developer.chrome.com/blog/responsive-iframes)).

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](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/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](https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md)).

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](https://developer.chrome.com/blog/responsive-iframes)).

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](https://developer.chrome.com/blog/responsive-iframes)).

## 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](https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md)).

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](https://developer.chrome.com/blog/responsive-iframes)).

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](https://developer.chrome.com/blog/responsive-iframes)).

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](https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md)).

<span id="why-it-matters-for-pwa-developers"></span>

## 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](https://developer.chrome.com/blog/responsive-iframes)).

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](https://developer.chrome.com/blog/responsive-iframes)).

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](https://www.bram.us/2026/09/23/responsive-iframes/)).

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](https://developer.chrome.com/blog/responsive-iframes)).

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](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/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](https://developer.chrome.com/blog/responsive-iframes)).

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](https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md)).

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](https://developer.chrome.com/blog/responsive-iframes)).

## Related entries

- [Platforms](/reference/platforms/): see platform model and terminology.
- [Baseline 2026](/reference/platforms/baseline-2026/): see record of the 2026 Baseline set.
- [By browser](/compatibility/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](https://www.bram.us/2026/09/23/responsive-iframes/) (bram.us)
- [Responsive iframes in Chrome 154](https://developer.chrome.com/blog/responsive-iframes) (developer.chrome.com)
- [Responsive iframes explainer](https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/responsive-iframes-explainer.md) (github.com)
- [`responsive-embedded-sizing` meta value](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/responsive-embedded-sizing) (developer.mozilla.org)