A real environment, isolated from everything
The playground stitches your HTML, CSS, and JavaScript into a single document and renders it live in a sandboxed iframe. The key design choice is isolation: because the iframe can’t reach the parent page, you can paste and run untrusted or experimental code with no risk to the surrounding application. That safety is the whole point — and it’s also the reason for the storage limitation above. Isolation and full origin access are mutually exclusive; the playground chooses isolation.
What it’s genuinely good for
| Use case | Why the playground fits |
|---|---|
| Prototyping UI | See markup + styles render instantly |
| Learning | Tweak code, watch the result change |
| Bug reproductions | A minimal, shareable repro of an issue |
| Teaching / demos | Live examples without local setup |
| Library evaluation | Try an API before adding it to a project |
The common thread is fast iteration on self-contained snippets — not building a full app with persistence and a backend.
Debugging with the captured console
The playground overrides the iframe’s console object and bridges log, warn, and error out to a visible pane, so console.log works just like in DevTools without opening them. A frequent gotcha: JavaScript that queries the DOM before the markup has rendered gets null. Wrap DOM access in a DOMContentLoaded listener, or place your script logically after the elements it touches, and the “cannot read property of null” errors disappear.
Loading external code safely
External scripts work as long as the CDN sends permissive CORS headers — stick to mainstream CDNs (unpkg, jsDelivr, cdnjs) and you’ll rarely hit a wall. If a script is refused, the cause is usually the source’s own Content-Security-Policy or a missing CORS header, not the playground. Load libraries in the HTML pane so they’re available before your JavaScript runs, and you can prototype anything from a vanilla DOM demo to a full Alpine or React component right in the browser.