Test if any URL can be
embedded in an iframe
Paste a URL and see in seconds whether the target site allows iframe embedding. Detect X-Frame-Options, CSP frame-ancestors blocks, and other common iframe errors - all in one place.
We don't store any URLs. All testing happens client-side in your browser.
Everything you need to debug iframes
Simple on the surface, thorough under the hood. Built for anyone who needs to work with iframes and embeds.
Instant results
Get a clear "loads" or "blocked" answer in seconds. No installs, no API keys, no account - just paste and test.
Header diagnostics
We surface the exact reason an embed fails - X-Frame-Options, Content-Security-Policy frame-ancestors, mixed-content, or browser console errors.
Smart timeout
If a page doesn't render in 10 seconds we stop waiting and tell you what likely went wrong, so you never sit watching a blank box.
Realistic preview
Your URL renders inside a browser-chrome mockup that mirrors a real embed scenario, perfect for screenshots and bug reports.
Shareable URLs
Every test produces a permalink. Send it to a teammate or paste it in a support ticket - they'll see exactly what you saw.
Privacy-first
We don't store URLs server-side and never run code on your behalf. The whole check happens inside your browser tab.
What exactly is an iframe?
An iframe (inline frame) is an HTML element that lets one webpage embed another inside it. Think of it as a window into another website: a video from YouTube, a map from Google Maps, a Stripe checkout widget - all the embeds you see across the web are usually iframes.
The catch: the site you're embedding decides whether it allows that. Servers send response headers - most commonly X-Frame-Options and Content-Security-Policy: frame-ancestors - that tell browsers whether to honour the embed. If they say no, your iframe shows a blank "refused to connect" page.
This tester reproduces that exact embed flow in your browser so you can find out, in seconds, whether a URL will work in your real product.
Built for anyone who works with embeds
From frontend developers to product managers running through a vendor demo, this tool answers one specific question fast.
Frontend developers
Verify that third-party widgets, dashboards, and microservices can be embedded before wiring them into your app.
SaaS & embed builders
If you ship an embeddable widget, use this to QA your X-Frame-Options and CSP headers on staging before release.
QA & support engineers
Reproduce customer-reported "blank iframe" bugs and capture a shareable link with diagnostics for the engineering team.
No-code & CMS users
Find out if a page can be embedded in your Webflow, WordPress, Notion or Wix site before wasting time on the build.
Security researchers
Audit clickjacking protections on a target site and see at a glance which framing headers it sets (or fails to set).
Marketing & ops
Confirm partner pages, landing pages and tracking pixels render correctly when embedded inside campaign tools.
What is clickjacking?
Clickjacking (also known as a UI redress attack) is a web security vulnerability where an attacker loads a legitimate website inside a transparent or visually disguised iframe on a page they control. The victim thinks they're clicking a harmless button - "Play video", "Claim prize", a CAPTCHA - but their click actually lands on a hidden element of the framed site, in a session where they're already logged in.
The consequences depend on what the hidden site allows with a single click: confirming a payment, granting an app permission, following an account, transferring credits, deleting data, or enabling a webcam. Because the user really did click, and really is authenticated, the action looks legitimate to the target server.
This is exactly why the X-Frame-Options and Content-Security-Policy: frame-ancestors headers exist - they let a site explicitly tell the browser "do not let anyone embed me in an iframe". You can use the tester at the top of this page to verify that your own site sets those headers correctly.
How to defend your site against clickjacking
A layered approach is best - start with the modern CSP directive, keep the legacy header for older browsers, then harden cookies and sensitive flows.
Set CSP frame-ancestors
This is the modern, primary defense. Send Content-Security-Policy: frame-ancestors 'none' to forbid all framing, or 'self' to allow only same-origin embedding. List explicit partner origins if you need cross-site embeds.
Add X-Frame-Options as a fallback
Older browsers ignore frame-ancestors. Also send X-Frame-Options: DENY or SAMEORIGIN so you're protected everywhere. When both headers are present, modern browsers prefer CSP.
Harden your cookies
Set authentication cookies with SameSite=Lax or SameSite=Strict so they aren't sent in cross-site iframe requests. Combined with Secure and HttpOnly, this blocks the attacker's session from being reused inside a frame.
Require confirmation on sensitive actions
For payments, account deletion, permission grants and similar one-click destructive actions, require a second step - typing a value, re-entering a password, or a 2FA challenge - so a single hijacked click can't do real damage.
Test before you ship
Paste your URL into the tester at the top of this page. If it loads inside the iframe, your site can be framed by anyone - and is exposed to clickjacking. If you see "refused to connect", your headers are doing their job.
Frame-busting JS as a last resort
If you can't set response headers (rare), a small script that checks window.top === window.self and breaks out of frames is better than nothing. It's bypassable, so always pair it with proper headers when you can.
Frequently asked questions
How do I load a webpage in an iframe?
Add an <iframe> element to your HTML and set its src attribute to the URL you want to embed, e.g.:
<!DOCTYPE html>
<html>
<body>
<iframe
src="https://example.com"
width="100%"
height="500"
loading="lazy">
</iframe>
</body>
</html>
If the target site allows embedding, you'll see the page render inside the frame. If not, browser security policies will block it, and the iframe will display an error. You can open the Console in the browser’s Developer Tools for debugging.
Why does the iframe show "refused to connect"?
The target site is sending headers that tell browsers to refuse the embed. The two most common are:
X-Frame-Options: DENY- blocks all framing.X-Frame-Options: SAMEORIGIN- only the same domain may embed it.Content-Security-Policy: frame-ancestors 'self'- the modern replacement for the above.
Only the site owner can change those headers. If you control the site, update them on your server. If you don't, you'll need a different integration - typically an official embed widget or an API.
What is the X-Frame-Options header?
X-Frame-Options is an HTTP response header that tells the browser whether a page is allowed to be rendered inside a <frame>, <iframe>, <embed> or <object>. It exists primarily to prevent clickjacking attacks. The valid values are DENY, SAMEORIGIN, and the now-deprecated ALLOW-FROM uri. Most modern apps use the CSP frame-ancestors directive instead, as it provides better protection.
What is CSP frame-ancestors and how is it different?
The frame-ancestors directive of the Content-Security-Policy header is the modern, more flexible replacement for X-Frame-Options. It can list multiple allowed parent origins and supports wildcards. Example:
Content-Security-Policy: frame-ancestors 'self' https://partner.com
When both headers are present, modern browsers prefer frame-ancestors and ignore X-Frame-Options.
What is clickjacking and how do I prevent it?
Clickjacking is an attack where a malicious page loads your site inside a hidden or transparent iframe and tricks visitors into clicking elements they can't see. Because the user is genuinely logged in, the click can trigger real actions - payments, permission grants, follows, deletions.
To defend against it, set Content-Security-Policy: frame-ancestors 'none' (or 'self' if you embed your own pages), add X-Frame-Options: DENY as a fallback for older browsers, use SameSite cookies, and require a confirmation step for sensitive one-click actions. See the full clickjacking guide above for details.
Can iframes access cookies from the parent page?
No, and this is by design. Iframes from a different origin can't read cookies, localStorage, or other data from the parent page (and vice versa), thanks to the browser's same-origin policy. Additionally, modern browsers block third-party cookies inside iframes by default, which can break embedded auth flows. If your embedded app relies on cookies, you'll need SameSite=None; Secure cookies and ideally a Storage Access API prompt.
What's the difference between iframe and embed/object?
<iframe> is the modern standard for embedding HTML pages. <embed> and <object> were originally designed for plugins (Flash, PDF, etc.) and are mostly legacy today. Stick with iframes unless you have a specific reason not to.
Is this tool free? Do you store the URLs I test?
Yes, it's completely free with no signup. We don't store the URLs you test on our servers - the entire check happens in your browser. The URL is only added to your address bar so you can copy and share the test link.
The page loads, but looks broken inside the iframe, why?
A few common causes:
- Responsive layout: the site assumes a wider viewport. Try increasing the iframe width or use
viewport-fitCSS. - Mixed content: if your parent page is HTTPS, an HTTP iframe will be blocked.
- JavaScript frame-busting: some sites detect they’re being framed and redirect away. No client-side workaround.
- Sandbox attribute: if you've set
sandboxtoo strictly, the page's scripts can't run.