testiframe.com

Can this website be embedded in an iframe?

Paste a URL to preview it in a live iframe. You'll also get the exact reason it loads or gets blocked: X-Frame-Options, CSP, cookies, redirects and more.

Try:

How the iframe tester works

When you test a URL, two things happen at once:

  • Live preview: your browser loads the page in a real <iframe> on this site, just like any third-party site would. You can switch between desktop, tablet and mobile sizes, toggle sandbox and allow attributes, and watch postMessage traffic.
  • Header check: our server fetches the URL as a browser loading it in an iframe would, follows every redirect, and reads the response headers. That tells you why it loads or doesn't, instead of leaving you with a grey "refused to connect" box.

Enter your own domain under "Would it load on your site?" and we'll evaluate the site's policy against your origin, because a site can allow some parents and block others.

Why a website won't load in an iframe

If you see "refused to connect", a blank frame, or the page jumps out of the frame, it's almost always one of these:

X-Frame-OptionsDENY blocks every parent site. SAMEORIGIN allows only the site's own pages.
CSP frame-ancestorsThe modern replacement for X-Frame-Options. It lists exactly which sites may embed the page, and overrides X-Frame-Options when present.
Mixed contentAn http:// page can't be framed inside an https:// page. The browser blocks it silently.
Frame-busting scriptsJavaScript that checks window.top !== window.self and redirects or hides the page.
Cookies & loginThe page loads but logs you out or loops, because third-party cookies are blocked or missing SameSite=None.
Bot protectionCloudflare or other WAF challenges often can't be completed inside a cross-site iframe.

Only the site owner can change these. They're enforced by the visitor's browser, so there's no legitimate client-side workaround. Full walkthrough: fixing "refused to connect" in an iframe.

How to allow your site to be embedded

Remove any X-Frame-Options header and send a Content-Security-Policy with frame-ancestors listing the sites allowed to embed you. 'self' keeps your own pages working.


          

To allow any site, use frame-ancestors * (or send neither header). Wildcards like https://*.example.com are supported. The old X-Frame-Options: ALLOW-FROM is ignored by modern browsers, so don't rely on it. More in X-Frame-Options vs CSP frame-ancestors.

How to prevent your site from being embedded

To protect against clickjacking, block framing entirely. Send both headers for coverage in old browsers:

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

Use frame-ancestors 'self' plus X-Frame-Options: SAMEORIGIN if your own pages need to frame each other. Note that frame-ancestors is ignored inside a <meta> tag, so it must be an HTTP header. See the clickjacking protection guide for per-framework configs.

Iframe cookie issues (SameSite, third-party cookies, CHIPS)

A page inside a cross-site iframe is in a third-party context. Its cookies are treated very differently than when you visit it directly:

  • No SameSite attribute means Chrome and Edge treat the cookie as Lax, so it's never sent in a cross-site iframe.
  • SameSite=Lax or Strict cookies are never sent to a cross-site iframe.
  • SameSite=None must also be Secure, otherwise the cookie is rejected outright.
  • Safari blocks third-party cookies by default, and Firefox partitions them per top-level site. A login made on your site won't carry into the iframe.
  • Partitioned (CHIPS) cookies get a separate cookie jar per embedding site. That's the most portable way to keep a session inside an embed.
  • To reuse a first-party login, call document.requestStorageAccess() (Storage Access API) from a user click inside the iframe. Add allow="storage-access" where required.

The Cookies tab above shows each Set-Cookie the page sends and whether it will survive in Chrome, Firefox and Safari. Deep dive: iframe cookies not working.

Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=None; Partitioned

Iframe embed code best practices

  • Always add a title so screen readers can describe the frame.
  • Use loading="lazy" for iframes below the fold. It's a free performance win.
  • Use CSS aspect-ratio for responsive video embeds instead of padding hacks.
  • Grant only the permissions you need via allow, e.g. allow="fullscreen; clipboard-write".
  • Embedding content you don't trust? Add sandbox and opt back in to only what's needed. Never combine allow-scripts and allow-same-origin for same-origin content, because it can remove its own sandbox (sandbox guide).
  • Need it to fit its content? See responsive and auto-height iframes.
<iframe
  src="https://example.com/embed"
  title="Product demo"
  style="width:100%;aspect-ratio:16/9;border:0"
  loading="lazy"
  allow="fullscreen; clipboard-write"
></iframe>

FAQ

Why does it say "refused to connect"?

The site sends X-Frame-Options: DENY/SAMEORIGIN or a frame-ancestors policy that doesn't include this site. Test it above to see which header is responsible.

Can I bypass X-Frame-Options?

Not from the embedding page. The visitor's browser enforces it. Proxying someone else's site to strip the header usually breaks logins and violates their terms. Ask the owner to add your domain to frame-ancestors.

The test says "embeddable" but my iframe is still broken

Check the Console and Cookies tabs. Common causes are login cookies blocked in third-party context, frame-busting JavaScript, or the page requiring permissions (camera, clipboard, fullscreen) that your allow attribute doesn't grant. Also test with your own origin, since frame-ancestors may allow some sites and not others.

Can I test localhost?

Yes. Browsers treat http://localhost as secure, so the live preview works for your dev server. The header check runs on our server and can't reach your machine, so read the headers from devtools instead.

Does this site store the pages I test?

No. Framed pages load directly from their origin into your browser. The header check stores only response headers, briefly cached for 5 minutes. No content is copied or hosted.

Why does the result differ from my browser?

Some sites send different headers based on location, cookies or bot detection. The live preview is always your browser's real behaviour. The header check shows what an anonymous first visit gets.

Iframe guides