When a page refuses to load in your <iframe>, an X-Frame-Options header or a Content-Security-Policy: frame-ancestors rule is telling the browser to block framing. This page explains what actually works to display such a site, what only works on your own machine, and what cannot work at all — with a live test you can run below.
You cannot bypass X-Frame-Options or frame-ancestors from inside an <iframe>. The browser enforces both, and no iframe attribute, sandbox value, or piece of JavaScript on the embedding page can override them.
The only way to display a page that blocks framing is to serve it from a different origin — one that does not send the blocking header. In practice that means a proxy: a browser extension or CORS proxy for local, throwaway use, or a hosted browser session such as Webfuse when you need a real, interactive, shareable embed in production.
If this stays blank or says "refused to connect", the site blocks framing.
Same URL, served from a different origin — the framing header no longer applies.
When your page tries to frame another site, the browser reads that site's response headers before rendering. If it finds X-Frame-Options: DENY / SAMEORIGIN or a frame-ancestors directive that excludes your origin, it discards the response and shows an error. Because the enforcement happens in the browser, nothing you write on the embedding page can undo it — the decision is already made by the time your JavaScript runs.
X-Frame-Options is the older header: DENY blocks all framing, SAMEORIGIN allows only the site's own pages. frame-ancestors is the modern Content-Security-Policy replacement and takes precedence where both exist — it can list exact allowed origins (frame-ancestors 'self' https://partner.com) or block everything with 'none'. Neither can be edited from the outside; only the site that sends them can change them.
Some sites also ship "framebusting" script that checks window.top !== window.self and redirects away when framed. A page can therefore pass the header check, load for a moment, then break out on its own. A sandbox attribute without allow-top-navigation stops that redirect, but it does nothing about the headers — the two protections are independent.
An extension (or a DevTools rule) strips X-Frame-Options and frame-ancestors from responses before the browser reads them, so framing succeeds. Only affects your own browser.
Works when: you just need to view or test a blocked page yourself.
Breaks when: nothing changes for your visitors — every user would need the same extension. Useless for a public site.
Starting Chrome with flags such as --disable-web-security turns off the checks entirely for that instance.
chrome --disable-web-security --user-data-dir=/tmp/devWorks when: a quick local sanity check during development.
Breaks when: it disables real protections and applies only to that one machine. Never do this in a browser you also use normally.
A public CORS proxy refetches the target page server-side and re-serves it without the blocking header. Libraries like x-frame-bypass wrap this in a drop-in <iframe> replacement.
<iframe is="x-frame-bypass" src="https://example.com/"></iframe>Works when: displaying a mostly-static page you do not control, for a quick demo.
Breaks when: relative URLs, cookies, login, and JavaScript-heavy apps break; public proxies are rate-limited and often blocked; you are trusting a third party with the traffic.
Run a server (nginx, a Worker, a Node app) that fetches the target and rewrites the response, dropping the framing header and fixing links.
Works when: you control the origin and can embed the result anywhere.
Breaks when: you rebuild session handling, auth, and asset rewriting yourself; datacenter IPs get bot-blocked by many sites; and interactive, logged-in apps are very hard to keep working.
The page runs in a real, hosted browser session served from its own origin and streamed back behind a shareable link, so the framing header does not apply and the site stays fully interactive.
Works when: you need a live, logged-in, clickable site embedded in production, shareable, with no install or extension — and optionally an AI agent acting inside it over MCP.
Breaks when: it is a hosted service rather than a one-line script, so it fits real products more than a throwaway static demo.
| Your goal | Use |
|---|---|
| View a blocked page yourself, once | Browser extension or DevTools header removal |
| Quick local dev check | Launch Chrome with --disable-web-security |
| Demo a static page you do not own | CORS proxy / x-frame-bypass (accept the limits) |
| Embed your own tool or dashboard | Send SAMEORIGIN or a frame-ancestors allowlist from your server — no bypass needed |
| Embed a live, interactive, logged-in site in production | Hosted browser session (Webfuse) |
| Let an AI agent act inside an embedded site | Hosted session with MCP (Webfuse) |
These headers exist to prevent clickjacking — an attacker framing a real site to trick a logged-in user into clicking something they can't see. Serving a page through a proxy to overlay or disguise it for an unaware user is exactly what the header defends against, and none of the methods here make that safe or acceptable.
The legitimate reasons to route around framing are ones where you control the context or the user knowingly joins: embedding your own dashboards and internal tools, building a kiosk or admin console, previewing pages you are authorised to test, or a co-browsing session a person deliberately opens. Those are the cases the proxy methods below are built for.
A CORS proxy can render static HTML, but breaks the moment a site needs login, cookies, or heavy JavaScript. To embed a page that people actually use — signed in, clicking, typing — Webfuse runs the page in a real browser session on its own origin and streams it back behind one shareable link. No install, no extension, and a human — or an AI agent connected over MCP — can see the DOM and act inside the session.
Not from the embedding page. X-Frame-Options is enforced by the browser using the target site’s response headers, so no iframe attribute or JavaScript on your side can override it. The only way to display the page is to serve it from a different origin that does not send the header — which is what a proxy does.
SAMEORIGIN allows framing only by the site’s own pages, so a page on another domain is blocked exactly like DENY. There is no attribute that grants an exception. If you own the site, change the header to a frame-ancestors allowlist. If you do not, route the page through a proxy so it is served from an origin you control.
For a mostly-static page you just want to display, often yes. But cookies, login, relative URLs, and JavaScript-heavy apps break, public proxies are rate-limited and frequently blocked, and you hand your traffic to a third party. It is fine for a demo, not for a site people log into and use.
It works the same way as X-Frame-Options and takes precedence where both are present. You cannot edit another site’s Content-Security-Policy from outside. Serving the page from a different origin is again the only route — or, if it is your own site, adjusting the frame-ancestors list.
The headers exist to stop clickjacking, so serving a real site through a proxy to trick an unaware user is the abuse they defend against. Routing around framing is legitimate when you control the context or the user knowingly joins — your own dashboards, internal tools, authorised testing, or a co-browsing session someone deliberately opens.
That message means the target sent X-Frame-Options or frame-ancestors and the browser blocked the frame. If it is your site, send SAMEORIGIN or a frame-ancestors allowlist that includes the embedding origin. If it is not your site, a plain iframe cannot fix it — use a proxy such as Webfuse that serves the page from its own origin.