HTML, CSS & JavaScript Playground — Run Code

What this playground does

This is a small, honest HTML editor: three text areas for markup, styles and script, one sandboxed iframe for the result, and a console that shows what the page logged. It is meant for the work that sits between “I have an idea” and “I have a project”: trying a CSS layout, checking a DOM API, demonstrating an event handler, or reducing a bug to ten lines before you take it back to your real codebase.

Press Run (or Ctrl/Cmd + Enter) to rebuild the preview. With Auto-run enabled, edits are debounced and re-run after a short pause, which is convenient for CSS but can be noisy for a script that logs on every line. The console is cleared on each run so the output you see belongs to the current version.

The panes use a code editor rather than plain text areas: syntax highlighting, line numbers, bracket matching, indentation and completion for common HTML tags, CSS properties and browser APIs. Hover a known function for its signature and a one-line explanation. The editor is loaded after the first paint, so the page itself stays light and the text areas remain usable while it arrives.

How the three panes combine

For a fragment, the HTML pane becomes the body of a new document. The CSS pane is placed in a <style> element in the head, and the JavaScript pane is placed in a <script> element at the end of the body, after your markup has been parsed. That is the usual order a browser would see, so document.getElementById() works without a DOMContentLoaded wrapper.

For a full document — anything starting with a doctype or an <html> element — the playground keeps your document and injects into it: the CSS and console bridge go at the top of the head, and the JavaScript goes before the closing body tag. Existing meta tags, links, inline scripts and styles are left alone. This is the path to use when you need to test a complete page rather than a fragment, for example a document with its own viewport meta tag or a script that must load in the head.

What the sandbox does and does not stop

The preview iframe carries sandbox="allow-scripts allow-forms allow-modals allow-popups" and deliberately does not carry allow-same-origin. Because its origin is opaque, the code inside cannot read this site’s cookies, localStorage or DOM, and it cannot navigate this tab. It can run scripts, submit forms to the preview itself, open the browser’s alert/confirm/prompt dialogs and open popups — the minimum needed for ordinary page experiments.

A sandbox is not a content filter. Code in the preview can still make network requests to origins that permit them, load remote images and fonts, and consume CPU or memory. If a snippet loops forever, press Run again, press Reset, or close the tab; the editor is a separate document and remains responsive in most cases. Treat the preview as a place for code you are willing to run, not as a malware scanner.

Reading the console

The Console panel is fed by a bridge injected before your markup. It forwards console.log, console.info, console.warn and console.error, plus uncaught errors and unhandled promise rejections. Arguments are joined with spaces; primitives use their normal string form, and objects are JSON-encoded when possible, with a fallback for circular structures. The panel keeps the last 200 lines so a loop that logs on every frame cannot grow the page without bound.

The bridge also reports when the document is ready, which is what changes the status line from “updating” to “preview updated”. The same messages are still written to the browser’s developer console, where objects remain expandable and stack traces are complete. If you are debugging a large object, open DevTools and use the console there instead of reading the JSON in this panel.

Common uses

• CSS layout practice. Change a grid, a flex container or a media query and see it without rebuilding a project.
• DOM API checks. Confirm what closest(), dataset or an event’s target actually returns before you rely on it.
• Teaching and code review. A small, complete example is easier to discuss than a full application, and the console makes the result visible.
• Reducing a bug. Copy the failing markup, styles and script into three panes and delete everything that does not reproduce it.
• Downloading a starting point. Build a small page, download the standalone file and open it in your editor.

Limits worth knowing before you start

Limit	Why	Workaround
No npm install or bundler	There is no build step; bare module imports are not resolved	Load a browser build from a CDN with a script tag or a full module URL
No site storage	The iframe has an opaque origin	Keep state in JavaScript variables; use your own app for persistence
CORS applies	The preview is not same-origin with the API you call	Use an API that sends the right CORS headers, or a local proxy outside this tool
No server-side code	Everything runs in the browser	This is not a Node, PHP or Python host; use a local runtime for server code
External assets need a network	Your browser fetches them from their own origins	Inline small assets as data URLs when the page must work offline

From playground to file

Download HTML assembles the same document without the console bridge and saves it as playground.html through a Blob URL. That file is self-contained with respect to your three panes; it is not a bundle of any external assets you referenced. If the page depends on a CDN script, an image or a font, those URLs remain in the file and still need a network when it is opened. For a genuinely portable artefact, inline the small pieces or keep the assets next to the HTML file.

Frequently asked questions

Go deeper

Longer explanations of the problems this tool solves:

Running code in the browser without a server

Sources

• WHATWG HTML Standard — the iframe element and the sandbox attribute, including the allow-scripts and allow-same-origin flags.
• MDN Web Docs — Window.postMessage() and the same-origin policy.
• MDN Web Docs — Content Security Policy, for the limits a host page can place on embedded documents.