UI Lab

Live Code Playground

Edit HTML, CSS, and JavaScript with Monaco. Preview updates instantly and console output is captured in a sandboxed iframe.

Tip: click the heading in the preview to test interactivity.
Layout
Loading editor…
DEBUG CONSOLE
0 messages

Console output will appear here when your code runs.

Live preview

A zero-setup front-end playground

This live code playground lets you write HTML, CSS, and JavaScript and see the result render in real time. It is powered by the Monaco editor — the engine behind VS Code — so you get syntax highlighting, bracket matching, multi-cursor editing, and familiar keyboard shortcuts right in the browser. There is nothing to install and nothing to configure; open the page and start building.

The reason a tool like this earns its place is friction. Checking whether a flexbox rule behaves the way you remember should take fifteen seconds, not the several minutes it takes to create a folder, initialise a project, install dependencies, and start a dev server. By the time the terminal is ready you have often forgotten the question. A scratchpad that is one tab away keeps you in the flow of whatever you were actually doing.

How it works

The three editor panels correspond to the three parts of a web page. What you type in the HTML panel becomes the document body, the CSS panel is injected as a stylesheet, and the JavaScript panel runs as a script once the markup is in place. Every keystroke re-assembles that document and re-renders the preview.

Your JavaScript runs inside a sandboxed iframe. That isolation is what makes the tool safe to use: code in the sandbox has its own document and its own global scope, so it cannot reach into the surrounding page, read your session, or interfere with the editor itself. From your code’s point of view it is a normal browser environment with a real DOM, so document.querySelector, addEventListener, timers, and the Canvas API all behave exactly as they would on a page you deployed.

Console output is intercepted before it reaches the browser’s own devtools and mirrored into the console panel below the preview. console.log, console.warn, console.error, and uncaught exceptions all show up there, which means you can debug an idea without leaving the page or opening a separate inspector.

What it is great for

The playground is deliberately a scratchpad rather than an IDE. Within that scope it handles a lot of everyday work:

  • Testing a CSS idea in isolation. Grid and flexbox behaviour is much easier to reason about when there are five elements on the page instead of five hundred, with no inherited styles muddying the result.
  • Reproducing a bug minimally. Stripping a problem down to the smallest markup that still shows it is the fastest way to understand it — and it produces exactly the reproduction a maintainer needs when you file an issue.
  • Learning and teaching. Seeing a change render the instant you type it makes concepts like specificity, the box model, stacking contexts, and event bubbling concrete in a way that reading about them does not.
  • Prototyping a component. Sketch the markup and interaction before committing to a framework, then port the parts that worked.
  • Checking a snippet before you paste it. Running unfamiliar code from an answer online in a sandbox is a good habit, and it takes seconds here.
  • Trying a browser API. Canvas, Web Animations, Intersection Observer, and similar APIs are much easier to explore interactively than from documentation alone.

Getting the most out of it

Run DOM code after the DOM exists

The single most common source of confusion in any playground is a script that queries an element before that element has been parsed. If querySelector returns null, this is almost always why. Either put the code inside a load handler or look the element up at the moment you need it:

JavaScript
document.addEventListener('DOMContentLoaded', () => {
  const btn = document.querySelector('#go')
  btn.addEventListener('click', () => console.log('clicked'))
})

Adding external libraries

There is no build step in the sandbox, so libraries have to arrive the way they would on a plain HTML page — as a script or stylesheet tag pointing at a CDN, added in the HTML panel. Browser-ready builds work directly. Anything that normally requires compilation, such as JSX, TypeScript, or SCSS, needs either a pre-compiled bundle or an in-browser transformer loaded alongside it.

Keyboard shortcuts

Because the editor is Monaco, the shortcuts you already use in VS Code carry over. The ones worth knowing:

ShortcutAction
Ctrl / ⌘ + FFind within the active editor panel
Ctrl / ⌘ + HFind and replace
Alt + ↑ / ↓Move the current line up or down
Shift + Alt + ↓Duplicate the current line
Ctrl / ⌘ + /Toggle a comment on the selection
Ctrl / ⌘ + DSelect the next occurrence of the selection
Alt + ClickAdd another cursor for multi-cursor editing
Ctrl / ⌘ + ZUndo

Copy anything you want to keep

The session lives in the page. Reloading or closing the tab clears it, which is the correct behaviour for a scratchpad but a nasty surprise if you have spent twenty minutes on something. When an experiment turns into something you care about, copy it out into a real project.

Limits worth knowing about

The sandbox is a real browser environment, but it is not your production environment, and a few differences matter:

  • Network requests to other origins are still subject to CORS. An API that does not send permissive CORS headers will fail here exactly as it would from any other page.
  • There is no bundler, module resolution, or transpiler, so bare import specifiers and framework syntax that needs compiling will not work without a CDN build.
  • Storage APIs behave according to the sandbox context rather than your own origin, so treat persistence as unavailable.
  • The preview is one viewport in one browser. It is a good first check, not a substitute for testing across the browsers and devices your users actually have.

None of these are problems for the use case the playground is built for — quick, isolated front-end experiments — but knowing where the edges are saves you from debugging the tool instead of your code.

Privacy

Everything you type stays in your browser. The code is assembled and executed locally in a sandboxed iframe, and nothing is uploaded, stored, or logged on any server, so you can paste in work-in-progress code without thinking about it. See the privacy policy for the full picture, and the disclaimer for the terms this tool is offered under.

Frequently asked questions

What is the code playground?+
It is a live, in-browser editor for HTML, CSS, and JavaScript. You write code on one side and see the rendered result update instantly on the other, with console output captured in a sandboxed iframe. It is ideal for prototyping UI, testing a snippet, or learning front-end concepts without any local setup.
Do I need to install anything?+
No. The playground runs entirely in your browser using the Monaco editor — the same editor that powers VS Code. There is nothing to download, configure, or sign up for, and it works on any modern desktop browser.
Is my code saved or shared?+
Your code stays in your browser session and runs in a sandboxed iframe for safety. Nothing is uploaded to a server, so you can experiment freely with private snippets. Closing or reloading the tab clears the session, so copy anything you want to keep.
What can I build with it?+
Anything that runs on the front end: layout experiments, CSS animations, small JavaScript demos, API-free component mock-ups, and quick reproductions of bugs. It is a fast scratchpad for ideas rather than a place to build a full application.
Can I use external libraries like React or Tailwind?+
You can add a library the same way you would on any HTML page, by including a script or stylesheet tag from a CDN in the HTML panel. Bear in mind that the sandbox has no build step, so anything requiring compilation — JSX, TypeScript, or SCSS — needs a browser-ready build or an in-browser transformer.
Why does my JavaScript not run when I expect it to?+
The most common cause is a script that runs before the elements it targets exist. Either place your DOM code at the end of the script, wrap it in a DOMContentLoaded listener, or query the element inside the handler rather than at the top level. Check the console panel — the error is usually a null reference.
Does the console show errors as well as logs?+
Yes. console.log, console.warn, console.error, and uncaught exceptions are all captured and displayed in the console panel, so you can debug without opening your browser developer tools.
Does it work on a phone or tablet?+
It loads on mobile, but the Monaco editor is designed for a keyboard and a large viewport. For anything beyond a quick look, a desktop or laptop browser is a much better experience.