Iframe Refused to Connect
Work through the failure in the right order: verify the URL, inspect framing headers, follow redirects, then check browser and application-specific behavior.
Start with the failure you can prove
1. Test the URL
Use the main iframe tester to check the final response, X-Frame-Options and CSP frame-ancestors.
2. Inspect DevTools
Check the final document request after redirects and read the browser console for a framing-policy violation.
3. Classify control
If you own the child page, fix its server policy. If you do not, switch to a supported embed or integration.
Cause 1: X-Frame-Options blocks the destination
DENY prevents framing. SAMEORIGIN is intended to allow framing only from the same origin. The parent page cannot remove either value from a remote site's response.
Cause 2: CSP frame-ancestors rejects the parent
A page can use Content-Security-Policy: frame-ancestors ... to specify allowed parent origins. This is often the most precise explanation when one production parent works and another does not.
Cause 3: the URL redirects somewhere else
The URL in your HTML may return a redirect to a login page, another hostname or a canonical route with stricter headers. Inspect the final response, not only the first request.
Cause 4: mixed content
An HTTPS parent should not depend on an insecure HTTP iframe. Use an HTTPS destination and confirm that every redirect stays on a secure origin.
Cause 5: authentication, cookies or storage
A framed application may rely on cookies that are restricted in a third-party context. Authentication flows can also refuse to run in frames. A page that appears public in your signed-in browser can behave differently when embedded.
Cause 6: JavaScript frame-busting
Header inspection can look permissive while application code deliberately detects a framed context, navigates the top window, hides the application or displays an error. The live browser preview helps reveal this gap.
Cause 7: same-origin policy confusion
A parent may successfully display a cross-origin iframe and still be unable to read its DOM. That is expected. Cross-origin DOM access requires an explicit communication design such as postMessage(), not a framing-header change.
A practical DevTools checklist
- Open the Network panel before reloading.
- Filter to document requests and select the iframe navigation.
- Follow the redirect chain to the final response.
- Inspect X-Frame-Options and Content-Security-Policy.
- Read the Console for framing, mixed-content, cookie or script errors.
- Replace the destination temporarily with a page you control to separate parent markup problems from destination policy problems.
Technical references
Blank iframe, refused connection or blocked script?
A Console message that names X-Frame-Options or frame-ancestors points to the destination's framing policy. A message naming frame-src points to the parent page's allowed frame destinations. Use the CSP builder to review the relevant directive on the correct page.
A mixed-content warning means an HTTPS page is trying to load an HTTP resource. A cross-origin DOM access error can occur after a frame loads successfully, so changing the destination's framing headers will not solve that script-access problem. Record the exact message before choosing a fix.
When the embed fails only in WordPress or a CMS
Inspect the published page's HTML to confirm that the iframe was preserved and its src is correct. Editors, plugins and sanitizers may remove unsupported markup or change attributes. If the iframe is present, check the final document request and framing headers next. The CMS cannot override a third-party site's denial.
Common questions
Why does an iframe say refused to connect?
A common cause is the destination page blocking framing with X-Frame-Options or CSP frame-ancestors. Redirects, authentication, mixed content, network errors and provider-specific logic can also cause an iframe to fail.
Can CORS cause the refused-to-connect message?
CORS is often blamed incorrectly. It mainly governs script access to cross-origin responses. An iframe navigation is controlled by framing policies and other browser security rules, although a framed app's own API calls can separately encounter CORS errors.
How do I inspect the iframe response headers?
Open browser developer tools, use the Network panel, reload the page and inspect the final iframe document request after redirects. Look for X-Frame-Options and Content-Security-Policy frame-ancestors.
Why does the page work in a tab but not inside the iframe?
Opening a page directly and embedding it are different browser contexts. A site can permit normal navigation while intentionally rejecting framing to reduce clickjacking or unsupported integrations.