TypeScript Playground — Run TS in Your Browser
A TypeScript scratchpad for execution, not type-checking: write TS, strip the types, and read the console output beside it. The transform and the sandbox both run in this tab.
Ready — press Run to transform the TypeScript and start the sandbox. Nothing is uploaded.
Type checking is intentionally absent. A type error can still run; use tsc
when the types themselves must be verified. Completion includes browser APIs, but DOM-only
APIs such as document are not available in the Worker.
What this playground does
This page runs TypeScript snippets in the browser. It transforms the source to JavaScript with Sucrase, then executes that JavaScript in a sandboxed iframe and shows the console output. It is meant for the same work as the JavaScript playground — checking a language detail, reducing a function, trying an async flow — with TypeScript’s annotations available while you write. The sandbox model is described in running code in the browser without a server.
The important distinction is between emitting and checking. TypeScript’s
compiler does both; this page does only the first. Type annotations, interfaces and type aliases
are removed before execution, and no type error prevents a run. That makes the tool fast and
small, but it also means a green run is not evidence that the types are correct. Use a local
tsc --noEmit or your editor’s language service for that job.
From TypeScript to a runnable snippet
When you press Run, the page loads Sucrase and calls its TypeScript transform with
disableESTransforms, so modern JavaScript syntax is not rewritten unnecessarily.
Interfaces, type aliases, annotations and type-only imports disappear. Constructs that need
runtime output, such as enums, are emitted. The resulting JavaScript is then passed to the same
sandbox used by the JavaScript playground; the sandbox never receives the TypeScript source.
If the transform fails, the parser error is shown in the output panel with its line and column, and no sandbox code runs. That is usually a syntax error — a missing brace, an incomplete generic or a type declaration the parser cannot finish. Type errors do not appear here because the type checker is not part of the path.
What is not available
The sandbox is a browser Worker inside an iframe, not Node and not a project build. There is no
tsconfig, no path mapping, no JSX configuration and no npm resolution. A bare import of a package cannot be
resolved; a dynamic import() of a full URL works when the origin allows CORS. The
parent page’s DOM, cookies and localStorage are out of reach because the Worker inherits the
iframe’s opaque origin. The tool shows console output rather than a rendered page, so use the HTML
playground for visual work.
The snippet is evaluated as an async function body after transformation. Top-level
await therefore works, and a returned promise is awaited before the run completes.
Classic import declarations are not supported as module syntax. The editor provides
TypeScript syntax highlighting, completion for common APIs and TypeScript constructs, hover
documentation and Ctrl/Cmd + Enter to run.
Stop, state and errors
Each Run evaluates the snippet as a new function body, so top-level declarations do not carry
from one run to the next; timers or properties deliberately left on self can linger
until the Worker is replaced. Stop replaces the entire iframe, which also terminates
its Worker; that is the reliable way to end a synchronous loop and the way to clear everything.
Errors are forwarded with their stack, and unhandled promise rejections and Worker errors are
reported even after the initial run has finished.
When to use it
- Checking emitted behaviour. See what an enum, optional property or async function actually does at runtime.
- Explaining a type-level idea with a runnable example. Keep the annotation, print the runtime value.
- Reducing a bug. Paste the smallest typed function that reproduces it and read the console.
- Comparing TS and JS output. Run the same logic on this page and the JavaScript playground.
Use a local project for anything that needs type checking, JSX, path aliases, package resolution, a debugger or persistent files. This tool is a scratchpad, not a replacement for the TypeScript compiler.
Privacy and cost
The transform and the sandbox are client-side. The source is sent to an iframe on the same page
with postMessage; it is not sent to this site or to Sucrase’s origin (Sucrase is
bundled with the page, not loaded from a CDN at runtime). If your snippet calls
fetch, that request goes where you point it, under the browser’s normal CORS rules.
The page has no account, no code endpoint and no server-side execution, and Stop leaves nothing
running in the tab.
Frequently asked questions
Is the TypeScript type-checked?
No. The page strips TypeScript syntax and runs the resulting JavaScript; it does not run the TypeScript compiler’s type checker. A type error such as passing a string where a number is declared will run if the JavaScript is valid. Use tsc locally or in CI when type correctness is the point — this playground is for execution, not for a clean type-check result.
How is the TypeScript transformed?
The page uses Sucrase, a fast syntax-only transform, in the parent tab before sending JavaScript to the sandbox. Interfaces, type aliases and type annotations disappear; enums and other constructs that need runtime output are emitted. Sucrase is loaded only when you press Run, so the page stays light until then.
Can I use tsconfig options, decorators or JSX?
There is no tsconfig and no project configuration. This transform covers ordinary TypeScript syntax and enums; JSX and path aliases are not configured, and decorator support is not a promise. For a project with compiler options, path mapping, JSX or type checking, use a local TypeScript setup.
Can I import npm packages or other files?
Bare imports such as import { z } from "zod" are not resolved: there is no bundler or node_modules in the sandbox. A type-only import is erased by the transform, so it costs nothing. Dynamic import() of a full URL works if that URL is reachable and CORS allows it. For packages, use your local project or a browser build loaded through the HTML playground.
Is my code uploaded?
No. The TypeScript is transformed in this tab and the resulting JavaScript is sent by postMessage through a sandboxed iframe to a Worker on the same page. There is no server-side execution path and no endpoint that accepts source. The page makes no request with your code.
Can I access the DOM or localStorage?
Not the parent page. The code runs in a Worker inside an iframe with an opaque origin; it cannot read this site’s DOM, cookies or localStorage, and a Worker has no DOM of its own. This tool shows console output rather than a rendered preview; use the HTML playground when you need a visible page.
What happens to an infinite loop?
Press Stop. The code runs in a Worker inside a sandboxed iframe, so the page discards the iframe and terminates the Worker without freezing the editor. The next Run starts a fresh Worker; variables and timers from the stopped run are gone.
Does top-level await work?
Yes. After the type syntax is removed, the JavaScript is evaluated as an async function body, so await can appear at the top level. A returned promise is awaited before the run is marked finished. Classic import declarations are still not module syntax in the sandbox; dynamic import() is the supported path.
Go deeper
Longer explanations of the problems this tool solves:
Sources
- TypeScript documentation — the type system, type-only imports and the difference between checking and emitting.
- Sucrase documentation — the TypeScript transform and its limits.
- MDN Web Docs — JavaScript async functions, dynamic import(), iframe sandbox and CORS.
- ECMAScript Language Specification — runtime semantics after types are removed.
Everything runs in your browser — nothing you type is uploaded.