Chrome 154 Responsive Iframe Tutorial: Auto-Size Embedded Content

Chrome 154 adds a new way to make an

When the browser supports the feature and both sides have opted in correctly, the iframe's height follows the embedded document rather than remaining at an arbitrary fixed height. If the child contains more content than the initial viewport, the parent frame can expand to accommodate that content instead of creating a second scrolling region.

Choose the right frame-sizing value

content-height is the most obvious value for an embedded widget because many iframes need a responsive height while their width follows the parent layout. The property also supports content-width, which makes the iframe's width follow the embedded document's layout width. Logical values, content-inline-size and content-block-size, allow the sizing direction to follow the iframe's writing mode.

For a conventional horizontally written web page, content-height is usually the value to test first. The distinction between physical and logical dimensions becomes useful when an application supports different writing modes. Do not use content-width simply because an iframe needs to be responsive horizontally; normal responsive CSS on the parent iframe can already control its width in many layouts.

Make the iframe resize after its content changes

The initial size calculation is not the whole story. Chrome does not continuously watch every layout change inside the embedded document and resize the iframe after each one. Instead, the child document can explicitly call window.requestResize() after it has changed its content.

Consider a comments widget that loads additional comments after the user clicks a button. The application can update the document first and then request a fresh size calculation.

async function loadMoreComments() {
  const comments = await fetchMoreComments();

  renderComments(comments);

  window.requestResize();
}

The order matters. Make all of the document changes first and call requestResize() after the new content has been inserted. This gives the browser a clear point at which to recalculate the embedded document's layout size instead of asking it to react to every intermediate change.

Why requestResize is different from the old postMessage pattern

The old approach required the child to calculate a numeric height, send that value to the parent, and then rely on parent-side code to apply it. The new API moves the measurement and application of that measurement into the browser. Your embedded code only needs to request another calculation when it knows its layout has changed.

That does not mean JavaScript disappears from every responsive iframe. If the embedded application has dynamic content, it still needs a way to know when a meaningful layout change has finished. What disappears is the custom communication protocol that used to shuttle measurements between two documents. This is a smaller programming model and, more importantly, it avoids maintaining a separate numeric representation of the child's layout in application code.

Use the opt-in carefully with cross-origin embeds

Responsive sizing also works with cross-origin iframes, but the embedded document controls which parent origins may receive its size information. The allow-origins value in the opt-in can be used to restrict that sharing rather than allowing every embedding origin.

Using a wildcard is convenient while testing, but a production widget that knows its permitted embedding sites has a reason to use a narrower policy. The browser still requires the embedded document to opt in, and the parent must still apply frame-sizing. If either side is missing, the responsive sizing relationship is not established.

Build a dynamic form without an iframe scrollbar

A multi-step form is a useful test because its height can change substantially during normal interaction. Imagine the first step contains only a name and email field, while the second step displays several additional questions. With a fixed iframe height, the second step can create an internal scrollbar even though there is plenty of space available in the parent page.

With responsive sizing enabled, the child can request another size calculation after switching steps. The basic structure looks like this:

function showStep(step) {
  document.querySelectorAll(".step").forEach((element) => {
    element.hidden = true;
  });

  document.querySelector(`[data-step="${step}"]`).hidden = false;

  window.requestResize();
}

The important sequence is to change the child document first and request the new measurement afterward. The parent does not need to receive a height value or update an inline height. The browser uses the embedded document's reported layout size to adjust the iframe itself.

Keep a fallback because browser support is limited

This feature is not yet something to assume every browser understands. MDN currently marks frame-sizing, responsive-embedded-sizing, and requestResize() as limited-availability experimental features, while current reporting shows support centered on Chromium-based browsers. Firefox and Safari do not currently provide the same responsive iframe sizing behavior. That makes progressive enhancement a better production strategy than replacing every existing iframe-sizing fallback immediately.

The safest approach is to make the embedded document usable at its default iframe size and then enable the new sizing behavior when the browser supports it. A fixed minimum height, an existing responsive iframe strategy, or a normal internal scrollbar can remain as the fallback. The new API should improve the experience in supporting browsers rather than determine whether the embedded content can be used at all.

Check the feature before shipping it

For a new Chromium-targeted application, test the complete parent-and-child pair in Chrome 154 or newer. Check the initial height, then test content that appears after page load, such as an expanded section, newly loaded comments, or a multi-step form. Also test the failure path by removing the opt-in or the frame-sizing declaration so you understand what your fallback looks like.

If the iframe is cross-origin, test the actual origin policy rather than relying only on a same-origin development setup. For a public site, test Firefox and Safari as well, because the absence of the feature should leave the content usable even if the automatic sizing does not happen. Once those tests pass, the next useful step is to replace any custom iframe height messaging in a Chromium-specific deployment with the native sizing mechanism, while retaining the existing fallback for browsers that have not implemented it.