How to fix an iframe that refused to connect
A blank frame is a symptom, not a diagnosis. Start with the response headers, then work through the browser’s other embedding rules.
1. Check the actual response
Open your browser’s developer tools and inspect the iframe document request in the Network panel. Look at the final URL, status code, and response headers. A redirect to a login or error page can introduce a different policy from the page you intended to embed.
The iframe header checker is a quick first pass for a public URL. It cannot reproduce your logged-in session, so compare its result with the browser if the two disagree.
2. Look for framing restrictions
X-Frame-Options: DENY disallows framing. SAMEORIGIN requires the ancestor pages to share the embedded page’s origin. With CSP, frame-ancestors 'none' blocks all parents; an allowlist blocks any parent that is not included.
If you own the embedded site, configure its HTTP response to permit the specific parent that needs access. For example, this policy allows the site itself and one trusted partner:
Content-Security-Policy: frame-ancestors 'self' https://partner.exampleMerge that directive into your existing CSP. Do not remove unrelated protections. If a CDN, framework, and web server each add policies, all enforced policies must allow the parent. Read how CSP and X-Frame-Options interact.
3. Check the parent page too
The parent’s frame-src policy controls which frames it can load. The child’s frame-ancestors controls who can embed it. These are different checks; fixing one does not fix the other.
A secure HTTPS parent generally cannot embed an insecure HTTP page. Use an HTTPS target, including throughout its redirect chain. CORS headers are not a replacement for framing permissions: adding Access-Control-Allow-Origin does not override X-Frame-Options or frame-ancestors.
4. Inspect sandbox and authentication behavior
A sandbox can prevent scripts, forms, popups, or storage access. Grant only the capabilities your integration needs. Separately, browser cookie restrictions can break a login flow that works in a regular tab. Inspect the browser’s Issues, Console, and Network panels; an external testing page cannot read another origin’s cookies or console.
What if you do not own the website?
Use the provider’s official embed URL, ask its owner to allow your origin, or link to the content. Client-side HTML cannot bypass an enforced framing policy. Proxying another site’s content is not an equivalent embed and can break scripts, authentication, and content permissions.
Why a load event is not a success signal
Browsers deliberately fire an iframe load event even when its content fails to load, and do not provide a dependable iframe error event. This avoids exposing information about protected destinations. Confirm the content visually and read the console before declaring the integration fixed.
References: MDN iframe element and MDN frame-ancestors.