What a playground is good for — and what it isn't
The biggest obstacle when picking up TypeScript is rarely the language. It's the road to it: install Node, create a project, make sense of tsconfig.json, pick a bundler. A good twenty minutes of setup pass before a single typed value gets checked — and none of it has anything to do with types.
A playground cuts that part away. You type, the compiler answers, and you watch the result at the same time. For learning individual concepts, sanity-checking a type idea or demonstrating something in an explanation, it's the shortest path there is.
What it isn't good for: anything spanning more than one file. No imports from npm packages, no tsconfig.json of your own, no interplay between modules. The moment experimenting turns into a project, TypeScript belongs on your machine. The playground is the workbench, not the workshop.
What actually happens in your browser
Plenty of online tools ship your input to a server, process it there and hand back a result. Not this one: the TypeScript compiler itself — the same library tsc uses on your machine — is loaded into your browser and runs inside a web worker, a separate thread alongside the page.
Two consequences follow. First, your code never leaves the device; there is nothing we could log, because nothing ever reaches us. Second, the interface stays responsive while the compiler works — a program this size on the main thread would freeze the page on every keystroke.
The price is size: roughly 2.1 MB compressed (compiler plus type definitions). That's why the compiler deliberately doesnot load on page view, but only once you press “Run” or start typing in earnest. Anyone who just reads this text never downloads it at all.
Why TypeScript 6 runs here, not 7
Since July 2026, TypeScript 7 has been the current release. It's a full rewrite of the compiler in Go — considerably faster, but also a native program. Since then the npm package no longer contains a typescript.js library but a platform-specific binary, and a binary cannot run inside a browser.
So this playground runs TypeScript 6.0.3: the last release with the classic JavaScript library. For everything you do in a playground — types, interfaces, generics, utility types, narrowing — it behaves like the current version. The version actually loaded is printed below the editor and read straight from the compiler rather than copied into this page by hand.
The three panels and what they tell you
JavaScript
The result of compilation. This panel gets most interesting when you switch the target from ES2022 to ES5: suddenly const turns into var, arrow functions become ordinary functions, and template strings become a chain of additions. Once you've seen what a compiler really does, you understand better why certain things used to be slow.
Equally instructive: the types have vanished entirely from the output. No: string, no interface. They exist only while checking.
Problems
Every compiler message with line, column and the official error number (such asTS2322). Clicking a message jumps to exactly that spot in the editor and selects it. Those numbers are worth knowing: they can be searched verbatim and lead to far more precise results than the error text.
Console
Everything your code prints through console.log. Objects are expanded readably, runtime errors show up in red with their message.
Type errors don't stop execution
If your code has type errors, it still runs here — and that isn't a shortcoming of the tool, it's how TypeScript genuinely behaves. Types are stripped during compilation, the emitted JavaScript is valid, and the browser executes it.
The command line works the same way: tsc writes the .js files even after complaining, unless you explicitly set noEmitOnError. It's one of the more useful realisations for beginners: TypeScript is an advisor, not a bouncer.It tells you where things don't line up; whether you listen is up to you.
Four things worth trying here
1. Toggle “strict” off and on. Take a function with an untyped parameter and watch TS7006 appear and disappear. It shows vividly how much of TypeScript's value hangs on that single option.
2. Swap any for unknown. With any the compiler accepts everything, including what crashes at runtime. With unknown it demands a check first. The difference is visible in five lines and explains itself.
3. Watch narrowing happen. Write a union type and test one field inside anif. In one branch the compiler knows different properties than in the other — that it works this out on its own is among the language's most elegant traits.
4. Apply utility types. Omit, Partial,Pick, Readonly: derive several interfaces from one instead of copying them by hand. Hover the derived type in the editor and you'll see what came out.
Frequently asked questions
What is a TypeScript playground?
An environment where you can write TypeScript, see type errors immediately and inspect the JavaScript it compiles to — with no Node.js, no npm install and no project folder. You type, the compiler answers. Exactly what a local tsc run gives you, minus the setup.
Is my code sent to a server?
No. The TypeScript compiler itself is loaded into your browser and runs there inside a web worker. Your input never leaves the device, there is no compile service behind this page and no sign-up. Once the compiler has loaded, the tool keeps working even with the network switched off.
Which TypeScript version runs here?
TypeScript 6.0.3 — the last release shipped as a JavaScript library, which is what makes it runnable in a browser. From version 7 onward the compiler is a native Go port distributed as a platform-specific binary, and a binary cannot execute inside a web page. The exact loaded version is printed below the editor, read straight from the compiler.
Why does the compiler only load on the first click?
Because it weighs roughly 2.1 MB compressed (compiler plus type definitions). Pulling that down on every page view would be rude to anyone who just wants to read the text, especially on mobile data. So the download starts when you press “Run” or begin typing in earnest — not before.
What does the “strict” option do?
It turns on the strict family of checks: no implicit any, null and undefined taken seriously, tighter function signatures. Nearly every serious project runs with strict enabled, because without it TypeScript gives away much of its value. Switch it off to see the difference — the same code will suddenly report far less.
Why does my code run despite type errors?
Because TypeScript types do not exist at runtime. The compiler strips them and emits ordinary JavaScript — even when it complained first. This is precisely how tsc behaves on the command line without the noEmitOnError option. A type error is advice to you, not a barrier for the browser.
Can I share my code?
Yes, via “Share link”. The code is encoded into the address itself rather than stored on a server. Whoever opens the link sees your version — and we do not. Very long code eventually exceeds what an address bar can hold; in that case the tool tells you instead of producing a broken link.
What is the “target” option for?
It sets which generation of JavaScript you compile to. On ES2022 modern code stays close to what you wrote. Switch to ES5 and you see what used to be necessary: const becomes var, arrow functions become regular functions, template strings become string concatenation. It is the most vivid way to understand what a compiler actually does.
Does this replace a real development setup?
No, and it is not meant to. There are no multiple files here, no imports from npm packages, no tsconfig.json, none of what makes a real project. The playground is for learning, checking an idea and demonstrating something — for a project, install TypeScript locally.