A JavaScript playground is a bounded editor that runs short JavaScript snippets locally inside an isolated environment, captures the console output and returned values, and stops execution before runaway code can freeze the rest of the page. The JavaScript Playground applies this pattern with a deliberate sandbox boundary: each snippet enters a fresh, unique-origin iframe, executes inside a dedicated Web Worker rather than on the UI thread, and is terminated after 1,500 milliseconds regardless of whether the code has finished. Network connections are blocked by Content Security Policy, the worker context exposes no DOM, window, localStorage, or cookies, and only the inline bootstrap plus a Blob-based worker are allowed to load. This makes the tool well suited to testing pure JavaScript — algorithms, arrays, strings, parsing, arithmetic, and language experiments — without standing up a full Node.js or browser project.
What the JavaScript Playground Actually Runs
The editor accepts a single, bounded JavaScript snippet up to 30,000 characters in length. Before the snippet reaches the iframe, the source is JSON-encoded and any less-than characters are escaped, so a string that contains a closing script tag cannot break out into iframe markup. Each click on Run creates a new isolated environment from scratch: a fresh unique-origin sandboxed iframe, a new Web Worker inside that iframe, and a cryptographically random per-run token that every outbound message has to carry. The result is treated as authentic only when the message source, a fixed marker, and the current token all match, which prevents an unrelated page or extension from injecting fake output into the result panel.
Execution happens in the Worker rather than the UI thread, which is why an infinite loop cannot freeze the parent page. The iframe's Content Security Policy denies all resources by default, blocks network connections, allows only the inline bootstrap and the Blob worker, and disables base URLs and form actions. The iframe itself permits scripts but rejects same-origin access, form submissions, navigation, popups, and downloads. Every run replaces the prior sandbox, so there is no carryover of variables, globals, timers, or worker handles from a previous attempt.
Running a Snippet in Three Steps
- Enter a bounded JavaScript snippet that does not require DOM or Node.js APIs. Paste code that uses only language features — variables, arrays, objects, strings, math, regular expressions, Promises, and standard built-ins. Anything that touches the document, the window, localStorage, fetch, or a Node.js-only global will either throw or be silently blocked.
- Select Run JavaScript to create a fresh isolated worker and sandbox. The playground discards the previous iframe, opens a new one with a unique origin, spins up a dedicated Web Worker, and posts your code into it. Each run is independent, so rerunning after a typo does not carry over any leftover state from earlier executions.
- Review console, result, error, or timeout output before changing and rerunning the code. Check the console panel for log and error messages, the result panel for the final expression's formatted value, the error panel for thrown exceptions, and the timeout panel if the worker was killed at 1,500 milliseconds. Adjust the snippet and run again.
Reading Console, Result, Error, and Timeout Output
Four output channels cover almost everything a short snippet can produce. The console captures every console.log and console.error call in execution order, which is where most short experiments report their findings. The result field reports the final expression's value when the worker can format it — JSON is used wherever possible, and a plain string is used as a fallback when JSON serialization would lose meaning or fail. Circular or unusual objects may therefore be simplified into a readable string you can interpret at a glance but cannot fully reconstruct.
If the snippet throws, the exception is surfaced as an error with its message and stack. Promises are awaited: a returned promise is followed until it settles or the 1,500-millisecond wall-clock guard fires, whichever comes first. When the guard fires, the worker is terminated, the parent page is unaffected, and the playground reports a timeout instead of a result. Because the timeout is a safety guard rather than a performance benchmark, the actual finishing time depends on browser scheduling and how much asynchronous work your snippet schedules.
What the Sandbox Deliberately Blocks
| Available inside the worker | Blocked or unavailable |
|---|---|
| Variables, literals, expressions | DOM access (document, elements, events) |
| Arrays, strings, objects, Maps, Sets | window, localStorage, sessionStorage |
| Math, Number, BigInt, JSON parsing | Cookies and page session state |
| Regular expressions | fetch, XHR, WebSocket, network requests |
| Promises, async/await, generators | Form submission, navigation, popups, downloads |
| Date, Intl, TypedArrays | Node.js-only APIs and npm packages |
| User-defined functions and classes | TypeScript compilation or transpilation |
| Console output capture | Persistent storage between runs |
The block list is enforced by the iframe's sandbox flags, its Content Security Policy, and the absence of those globals inside the Worker context — not by an honor system inside the page. If you need any of the blocked capabilities, you will need a different tool: a local Node.js environment, a browser DevTools console, or a version-controlled project with the runtime that will actually execute the code in production.
Good Fits for the Playground
The sandbox is built for short, deterministic experiments that exercise pure JavaScript. That includes array and string transformations, small parsing routines, regular-expression sketches, math and BigInt experiments, JSON serialization checks, and tiny algorithms you want to validate before promoting them into a larger project. Promises can be tested up to the 1,500-millisecond cutoff, which is enough for almost any practical snippet that does not depend on real network I/O.
Because every run is a fresh environment, you can iterate quickly without cleaning up globals, timers, or stray event listeners between attempts. If a snippet throws, fix the code and rerun; the previous worker has already been replaced. If a snippet silently returns nothing, add a console.log of the intermediate value and check the console panel on the next run.
Limits Worth Knowing Before You Paste
The editor caps snippets at 30,000 characters, which is generous for almost any self-contained experiment but smaller than many real source files. The tool stores no projects and provides no imports, packages, Node.js APIs, TypeScript compilation, debugging breakpoints, or persistent files. Every run is a single, isolated execution: there is no state to save, no history of previous runs, and no way to chain multiple snippets in one session.
The 1,500-millisecond timeout is a wall-clock guard against runaway code, not a benchmark of how fast your snippet runs. Browser scheduling varies, so asynchronous work may be terminated before completion even when the snippet is well-behaved. For code that needs persistence, imports, debugging, or a richer runtime, set up a version-controlled local project with tests, linting, dependency review, and the runtime that will actually execute it.
The sandbox is a defense boundary, not an invitation to run unknown or untrusted code. Review snippets before execution and never paste passwords, API keys, session tokens, private customer data, or proprietary source into any online editor, this one included. The isolation protects the page you are reading; it does not protect secrets you voluntarily hand to a remote service.
For background on the underlying mechanics — Web Workers, the sandbox attribute on iframes, and Content Security Policy — the MDN Web Workers API reference and the MDN iframe sandbox documentation describe each piece in detail.