RESPONSIVE IFRAME

FAQ

What is this site not?

It is not a hosted iframe CDN, not Iframely, not a visual WYSIWYG embed editor, and not a polyfill that invents frame-sizing in unsupported browsers. It only builds paste-ready snippets for pages you control. If you need a managed oEmbed provider, use a commercial embed product instead.

Why must the meta tag be in the first HTML response?

Chrome’s responsive iframe design requires the embedded document to opt in before (or as) it loads. Adding <meta name="responsive-embedded-sizing"> with JavaScript after the document has already loaded will not turn the feature on. Put the tag in your server-rendered or static <head>.

Do I still need postMessage height code?

Often yes, for a while. Use @supports (frame-sizing: content-height) so supporting browsers use the new path while older browsers keep your fixed height or existing messenger. Remove the legacy path only when your analytics show enough support for your audience.

What about cross-origin embeds and security?

Responsive sizing can work cross-origin when the embed lists parent origins in allow-origins. Prefer an explicit allow-list for third-party widgets. This complements — it does not replace — frame-ancestors CSP and normal iframe sandbox decisions. Never treat * as “secure by default.”

Is my data uploaded?

No. Origins, paths, titles, and CSS options stay in your browser tab. See the privacy page. We do not create accounts or store pasted snippets on a server.

Which browsers support this today?

Treat Chromium with the Chrome 154+ responsive iframe feature as the primary target, and verify on your own builds. Firefox and Safari support should be checked against current MDN compatibility tables before you drop fallbacks. This site does not claim universal support.