Can CSS Auto-Size a Cross-Origin iframe Now?
A comment widget keeps outgrowing its iframe, and Chrome 154 now sizes frames to their content. What does the embedded page have to do before that works?

- Chrome 154 supports sizing an iframe to the embedded document’s content.
- The parent’s CSS needs an opt-in from the child; arbitrary third-party embeds cannot be forced to participate.
- Dynamic changes need requestResize inside the frame, with existing sizing retained for unsupported browsers.
Yes, if the child agrees to share its size
Chrome 154, released to stable on September 22, adds content-based iframe sizing. It offers a native alternative to measuring a document and sending its height to the parent with postMessage. It does not let a parent unilaterally resize any third-party embed to its contents.
The child needs a responsive-embedded-sizing meta tag to share layout dimensions. If you own only the embedding site, your widget provider must participate. Owning both documents makes the feature much easier to adopt.
The parent then uses frame-sizing to choose the dimension supplied by that content. For a comment widget that grows vertically, content-height is the relevant value.
Set parent CSS and a child opt-in
This example keeps a 480px fallback and switches to content height where the property is supported. The fallback size is a design choice, not a requirement of the API.
.embed {
width: 100%;
height: 480px;
}
@supports (frame-sizing: content-height) {
.embed {
height: auto;
frame-sizing: content-height;
}
} In the embedded document’s initial head, authorize the parent’s origin. Replace this example origin with the actual embedding site.
<meta name="responsive-embedded-sizing"
content="allow-origins=https://publisher.example"> The Chrome guide says adding the meta tag dynamically after the document loads does not enable the feature. Separate multiple allowed origins with spaces. Permission to share dimensions also serves a different purpose from CSP’s frame-ancestors, which governs who may embed the document.
Request another measurement inside the iframe
The browser does not continuously watch every layout change. According to the requestResize reference, the child reports its initial layout size at DOMContentLoaded and again at load. Later changes, such as expanding a panel or adding comments, need another report.
After updating the content, run this inside the embedded page:
if ("requestResize" in window) {
window.requestResize();
} Calling it from the top-level parent raises NotAllowedError. So does calling it without the child opt-in. A different failure is quieter: if the child is configured correctly but the parent lacks frame-sizing, the call does not throw, yet the iframe remains unchanged.
Replace the messaging only where both sides support sizing
A successful @supports query confirms CSS support, not the provider’s consent to share dimensions. Enable the new path for embeds whose child configuration you control or have verified.
Keep fixed sizing or the existing message-based resizer for unsupported browsers. MDN does not mark these related features as Baseline. Content-sized frames can also move surrounding content when the child loads later, so check the initial viewport rather than assuming fewer sizing scripts mean a steadier layout.
The useful change is that browsers can take over the size calculation exchanged between cooperating documents. It is ready to simplify that arrangement; it is not a CSS escape hatch for a third-party document you cannot change.