CodePen Pen works in editor but breaks in Preview, Debug, or embeds

The problem and what to check first

You open a CodePen Pen and the HTML, CSS, and JavaScript panes look correct, but Preview shows a blank pane, missing styles, or a script that never runs. Debug view and third-party embeds behave the same way. The editor's built-in console may stay silent, so an empty log is not proof that the Pen is healthy.

The useful takeaway is that the editor pane is not a reliable proxy for the rendered Pen. CodePen serves Pen output inside a sandboxed iframe, and embeds are served from a different origin than the editor preview. Relative URLs, cookies, localStorage, and cross-frame access cannot be assumed to behave like a local development server. If a Pen works in the editor but fails outside it, the failure is almost always a load-time resource block or a sandbox restriction that only appears in the rendered iframe.

Recognizable condition

Start here if one or more of the following are true:

• The output pane is blank, white, or missing styles in Preview, Debug view, or an embed, while the code panes look correct.
• JavaScript runs in the editor but throws or does nothing in Debug view or embeds.
• The CodePen editor console shows no errors, yet the rendered page is visibly broken.
• The Pen works in Preview but fails in an embed, or vice versa.

Cause and diagnostic table

Symptom	Likely cause	Where to confirm
Blank pane or missing CSS	Blocked external stylesheet: HTTP mixed content, 404, or Content Security Policy	Debug view, browser DevTools Network tab
JavaScript throws only after interaction	Sandboxed iframe blocks storage, popups, alerts, or top navigation	Debug view, browser DevTools Console tab
Editor console silent, page broken	Editor console captures a subset of preview messages; early load errors can be missed	Real browser DevTools in Debug view, not CodePen's console
Works in Preview, fails in embed	Different origin and sandbox flags between editor preview and embed context	Test the exact embed surface you ship

Ordered checks

1. Reproduce in Debug view. Open the Pen and choose Debug view (full-page render). Confirm the failure exists outside the editor chrome. If it renders fine here, the issue may be specific to Preview or the embed context.
2. Open browser DevTools in Debug view. Press F12 or right-click and choose Inspect. Open the Network tab, reload the page, and record status codes for every external request. Look for mixed-content warnings, CSP violations, CORS errors, and 404 responses.
3. Check the Console for uncaught errors. Note whether errors appear at load time or only after a user interaction. Distinguish real runtime exceptions from CodePen console capture gaps.
4. Inspect compiled output. If you use CSS or JavaScript preprocessors, open Settings and review the compiled CSS and JS panels. Confirm what CodePen actually serves, not what you wrote in the source panes.
5. Test the embed context. Load the Pen in an embed, or embed it in a local HTML page using the same embed URL. Re-check Network and Console after each change, because origin and sandbox rules can differ from the editor preview.
6. Build a minimal baseline. Create a new Pen with plain HTML, CSS, and JavaScript, no external resources, and no preprocessors. If it renders, add dependencies back one at a time until the failure returns.

Fixes tied to findings

Blocked external resource

If Network shows a blocked or failed request for an external stylesheet or script, replace http:// or protocol-relative URLs such as //example.com/asset.css with absolute HTTPS URLs like https://example.com/asset.css. Re-add the resource in CodePen Settings under the appropriate CSS or JavaScript external resource field. Use exact case in the URL; relative asset paths are case-sensitive and resolve against CodePen's serving context, not your local project root.

Risk: Changing a URL to HTTPS can break the resource if the remote host does not support HTTPS. Verify the HTTPS URL loads directly in a browser before adding it to the Pen.

Sandboxed iframe storage restrictions

If the Console shows errors involving localStorage, sessionStorage, cookies, or cross-frame access, the sandboxed iframe is likely blocking that API. Feature-detect storage and wrap access in try/catch, falling back to an in-memory object when storage is unavailable. Do not store secrets, authentication tokens, or personally identifiable information in a Pen; sandboxed iframes and public URLs make them unsuitable for sensitive data.

Missing or incorrect compiled output

If preprocessors are enabled, the source panes may not match the served output. Inspect the compiled CSS and JavaScript in Settings. Confirm external URLs point to published assets, not local file paths such as ./style.css or C:/project/script.js, which have no meaning in CodePen's serving context.

Embed-specific failure

If the Pen works in Debug view but fails in an embed, test the exact embed URL and embed code you plan to ship. Embeds can be served from a different origin than the editor preview and may carry different sandbox flags. Do not assume the editor preview matches the embed.

Escalation criteria

Escalate to CodePen support only after both of the following are true:

• A minimal Pen with plain HTML, CSS, and JavaScript, no externals, and no preprocessors still fails in Debug view.
• Compiled output or served Pro assets look inconsistent with what you configured in Settings.

When you contact support, include the Pen URL, browser and operating system, exact steps to reproduce, and the minimal reproduction Pen. Do not include secrets or PII.

Limitations and practical verification

CodePen's iframe sandbox, Content Security Policy, and Pro asset hosting behavior can change over time. Treat exact policy details as version-sensitive and verify them in the current product. Do not treat silence in the editor console as success; confirm with Debug view and real browser DevTools before closing an issue.

After applying a fix, reload Debug view and check that external requests return 200, the Console shows no new uncaught errors, and the embed context renders correctly. If the minimal baseline Pen works but the full Pen fails, the culprit is one of the dependencies you added back during the ordered checks.