Chrome Responsive Iframe Sizing: Setup and Fallbacks

A full-width iframe is not necessarily a content-height iframe. A comment widget or signup form can fit the article column horizontally while still clipping content or creating a second scrollbar vertically.

Chrome 154 introduces native content-based iframe sizing with frame-sizing: content-height. It requires cooperation from both documents: CSS on the publisher’s iframe and an opt-in meta tag inside the embedded page. Chrome’s September 22, 2026 release announcement confirms the feature is rolling out. As of October 1, 2026, MDN marks the associated requestResize API as experimental and not Baseline; preserve cross-browser fallbacks.

Choose the sizing model first

For a video player with a known shape, a fixed ratio is usually the appropriate model. For example, width: 100%; height: auto; aspect-ratio: 16 / 9 defines a box whose height follows its width. CSS aspect-ratio describes the box’s proportions—not the embedded document’s content height—and requires at least one automatic dimension. See MDN’s aspect-ratio documentation.

For a variable-height document, such as comments, a form with validation messages, or an expanding information panel, content-based sizing is the better candidate.

If you cannot edit the embedded page and its provider has not enabled the opt-in, parent CSS alone cannot activate the feature. Keep the provider’s supported sizing integration or an intentionally sized, scrollable frame.

Configure the parent and child

The following is an illustrative integration for a publisher-controlled comments page, not a reported production deployment.

On the parent page, give the comments iframe the class comments-embed, a src pointing to /comments.html, and a descriptive title such as Comments. Keep a fixed-height fallback and enhance only the iframe intended for content-based sizing:

.comments-embed {
  display: block;
  width: 100%;
  height: 500px;
  border: 0;
}

@supports (frame-sizing: content-height) {
  .comments-embed {
    height: auto;
    frame-sizing: content-height;
  }
}

The 500px value is an example fallback, not a recommended universal height. Choose it for the actual widget, or preserve an existing scripted sizing fallback.

In the embedded page’s head, add a meta element with these attributes:

• name="responsive-embedded-sizing"
• content="allow-origins=https://publisher.example"

Replace the example origin with the real embedding origin. Chrome also documents allow-origins=* and space-separated lists of origins. For a widget serving known publishers, prefer an explicit list. This permission governs responsive sizing; it does not replace embedding security controls such as CSP frame-ancestors. The syntax, origin restrictions, and progressive-enhancement pattern are documented in Chrome’s responsive iframe guide.

A CSS feature query checks browser support, not whether the child has opted in. Apply this enhancement only to integrations whose embedded document you have verified.

Request updates after dynamic changes

Native sizing is not a continuous observer of every change inside the iframe. MDN documents automatic size reporting at DOMContentLoaded and load; later changes can require window.requestResize() from the embedded document. See the requestResize API documentation.

For example, this function belongs inside the opted-in comments document:

function appendComment(text) {
  const paragraph = document.createElement("p");
  paragraph.textContent = text;
  document.body.appendChild(paragraph);

  if ("requestResize" in window) {
    window.requestResize();
  }
}

Batch DOM changes, then request recalculation before layout, as Chrome recommends. Include later-loading content in that lifecycle rather than assuming the initial load covers it.

The method’s presence alone does not establish permission: MDN documents NotAllowedError when it is called from a top-level document or without the child opt-in. Keep this code in the intended embedded context. If the parent has not enabled content-based frame-sizing, the call does not throw for that reason, but the iframe will not resize.

If your existing integration measures height and sends it through postMessage(), retain that route for fallback environments. Coordinate the parent and child so the legacy height updater does not keep writing inline heights while native sizing is active.

Verify the reader experience before rollout

Content-height sizing can remove unnecessary internal scrolling, but expanding an embed can still move the article below it. web.dev’s CLS guidance identifies embeds and iframes without reserved dimensions as common sources of layout shifts.

Use this proposed acceptance checklist:

• Initial render: check short and long content, plus slow and failed loads.
• Dynamic states: add comments, show validation errors, and expand or collapse panels. Confirm resizing in both directions.
• Responsive layout: test narrow and wide article columns, then resize the viewport after loading.
• Fallback behavior: test a browser without support and a child without the opt-in. Content must remain accessible.
• Page stability: record loading and interactions in Chrome DevTools’ Performance panel; inspect its Layout shifts track, not just a final screenshot.

Where embed heights are predictable, reserve suitable space in the surrounding layout. Where they are not, evaluate the tradeoff between whitespace, internal scrolling, and movement of nearby content. Use the visual regression testing workflow to compare those states, with performance recordings alongside it: a screenshot can reveal clipping, but it cannot establish layout stability.