Blog Post

52% of Websites Block iframes: What We Found Testing 184 Sites

By Emilia Veras, Founder & Product Designer at OverlayQA. Last updated: August 11, 2026

The Finding

Every tool that previews, proofs, or annotates a website in the browser has the same hidden dependency: it assumes the site will render inside an iframe. That assumption fails on half the web.

Our free responsive tester loads a submitted URL into five viewports at once and records how many frames loaded and how many were refused. Over roughly nine weeks that produced 523 scans across 184 distinct domains, submitted by real users testing their own sites.

We took the most recent scan per domain, so a site that was fixed mid-session counts as fixed. Using the looser rule instead, counting any domain that ever blocked, moves the number to 55.4%. The finding is not sensitive to that choice.

Blocking Is All or Nothing

Of the 184 domains, 96 blocked every single viewport and 88 loaded every single viewport. Not one domain was partial.

That rules out the obvious objection. If these were flaky network failures or slow frames timing out, we would expect a spread: some sites loading three of five viewports, others loading four. Instead the distribution is perfectly binary. Embedding refusal is a property of the site, decided by a response header, not an artifact of the test.

How Sites Block: X-Frame-Options vs CSP frame-ancestors

Our pre-flight check records why a frame was refused. Among the 50 blocked URLs where it captured a specific reason, 34 (68%) used the legacy X-Frame-Options header and 16 (32%) used the modern Content-Security-Policy: frame-ancestors directive. This is a subset of all blocked domains, so treat the split as indicative rather than exact.

Both exist to stop clickjacking. Per MDN, frame-ancestors takes precedence over X-Frame-Options where both are present. The original header is specified in RFC 7034, and MDN documents the current behaviour.

The point is not that sites are wrong to send these headers. The point is that two thirds of the blocking we saw comes from a blanket header with no allowlist, so there is no origin a review tool could ask to be added to.

What This Breaks

If a product renders customer websites in an iframe, roughly half of prospective customers will see a blank panel on their first attempt. That includes website preview widgets, visual feedback and proofing tools, responsive testers, screenshot services built on frames, and any onboarding flow that says "paste your URL to get started."

• Logged-in and staging environments almost always send strict headers, and those are exactly the pages a QA team needs to review.
• The user cannot fix it from their side without changing server configuration, which is usually not theirs to change.
• The error surfaces as an empty box, so the tool absorbs the blame.

What To Use Instead of an iframe

This is why OverlayQA is built as two paths rather than one. Public URLs open directly in the dashboard through a server-side proxy, with no install. Localhost, staging, and login-gated pages use the Chrome extension, which runs inside the page the reviewer is already looking at and never needs permission to frame it.

Limitations

This is a sample of sites people chose to paste into a free responsive tester, not a random sample of the web. It skews toward indie sites, staging environments, agency client work, and hosted platform builds. We would expect a crawl of the top 10,000 domains to return a different and probably higher number.

• n = 184 domains. Large enough to be indicative, small enough that a few points of movement are noise.
• Sample is self-selected, so read it as "52% of sites people test" and not "52% of the web."
• The mechanism split comes from 50 URLs where a reason was captured, which is a subset of the 96 blocked domains.
• We deduplicated per domain and used the latest scan. 76% of tested URLs were rescanned at least once, so counting raw scans instead would understate the rate.

Can I check whether my own site blocks embedding?

Yes, in two ways. Load your URL in our free responsive tester, which tells you immediately if the frames are refused. Or inspect the response headers directly with curl -sI https://yoursite.com | grep -i "x-frame-options\|content-security-policy". If either header is present with DENY, SAMEORIGIN, or a frame-ancestors list that excludes the tool you are using, the frame will be refused.

Should I remove these headers so review tools work?

No. They are a legitimate clickjacking defence and removing them to accommodate a QA tool trades a real security control for convenience. Choose a tool that does not need the frame instead. If you do need to allow one specific origin, frame-ancestors supports an allowlist and X-Frame-Options does not.

Related Resources

• Free Responsive Tester — load any URL at five viewports and see if it refuses to embed
• Team Review — capture issues on any public URL with no extension install
• Visual Comparison — compare Figma designs against live builds
• Website QA Checklist — what to verify before launch
• Visual Feedback Tools — how browser-based feedback tools differ
• OverlayQA — Detect visual and accessibility bugs on any URL and export complete, reproducible issues to Jira, Linear, Notion, Asana, or Trello