TypeScript Playground

TypeScript tippen und sofort sehen, was der Compiler dazu sagt: Typfehler mit Zeilennummer und Fehlercode, daneben das erzeugte JavaScript — und ein Klick, um es auszuführen.Ohne Installation, ohne Anmeldung, ohne Upload.

Compiler läuft in deinem Browser
  1. 1
    SchreibenTypeScript tippen oder ein Beispiel laden. Tab rückt ein, Strg+Enter führt aus.
  2. 2
    PrüfenTypfehler erscheinen beim Tippen, mit Zeilennummer und Fehlercode zum Anklicken.
  3. 3
    AusführenDas erzeugte JavaScript läuft direkt im Browser, console.log landet in der Konsole.
100 % lokal im Browser
TypeScript
TypeScript

Der Compiler wird erst geladen, wenn du ihn brauchst (rund 2,1 MB). Danach läuft alles offline.

Wofür ein Playground gut ist — und wofür nicht

Die größte Hürde beim Einstieg in TypeScript ist selten die Sprache. Es ist der Weg dorthin: Node installieren, ein Projekt anlegen, tsconfig.json verstehen, sich für einen Bundler entscheiden. Bis der erste getippte Wert überhaupt geprüft wird, sind gut zwanzig Minuten Einrichtung vergangen — und keine davon hat etwas mit Typen zu tun.

Ein Playground schneidet diesen Teil ab. Du tippst, der Compiler antwortet, du siehst gleichzeitig das Ergebnis. Zum Lernen einzelner Konzepte, zum schnellen Prüfen einer Typ-Idee und zum Vorführen in einer Erklärung ist das die kürzeste Strecke.

Wofür er nicht taugt: alles, was mehr als eine Datei hat. Keine Imports aus npm-Paketen, keine eigene tsconfig.json, kein Zusammenspiel mehrerer Module. Sobald aus dem Ausprobieren ein Projekt wird, gehört TypeScript lokal installiert. Der Playground ist die Werkbank, nicht die Werkstatt.

Was hier tatsächlich im Browser passiert

Viele Online-Werkzeuge schicken deine Eingabe an einen Server, lassen sie dort verarbeiten und liefern das Ergebnis zurück. Hier nicht: Der TypeScript-Compiler selbst — dieselbe Bibliothek, die auch tsc auf deinem Rechner benutzt — wird in deinen Browser geladen und läuft dort in einem Web Worker, also in einem eigenen Ausführungsstrang neben der Seite.

Das hat zwei sichtbare Folgen. Erstens verlässt dein Code das Gerät nicht; es gibt nichts, was wir protokollieren könnten, weil bei uns nie etwas ankommt. Zweitens bleibt die Oberfläche bedienbar, während der Compiler arbeitet — ein Programm dieser Größe im Haupt-Strang würde die Seite bei jedem Tastendruck kurz einfrieren.

Der Preis dafür ist die Größe: rund 2,1 MB komprimiert (Compiler und Typdefinitionen zusammen). Deshalb lädt der Compiler bewusstnicht beim Seitenaufruf, sondern erst, wenn du auf „Ausführen" klickst oder anfängst zu tippen. Wer nur diesen Text liest, lädt ihn nie.

Warum hier TypeScript 6 läuft und nicht 7

Seit Juli 2026 ist TypeScript 7 die aktuelle Version. Sie ist ein vollständiger Neubau des Compilers in Go — deutlich schneller, aber eben auch ein natives Programm. Das npm-Paket enthält seither keine typescript.js-Bibliothek mehr, sondern eine plattformspezifische Programmdatei. In einem Browser lässt sich die nicht ausführen.

Deshalb läuft hier TypeScript 6.0.3: die letzte Fassung mit der klassischen JavaScript-Bibliothek. Für alles, was man in einem Playground tut — Typen, Interfaces, Generics, Utility Types, Narrowing — verhält sie sich wie die aktuelle Version. Die tatsächlich geladene Versionsnummer steht unter dem Editor und wird direkt aus dem Compiler ausgelesen, nicht aus dieser Seite abgeschrieben.

Die drei Anzeigen und was sie dir sagen

JavaScript

Das Ergebnis der Übersetzung. Am aufschlussreichsten wird dieser Bereich, wenn du das Ziel von ES2022 auf ES5 stellst: Plötzlich siehst du, wie aus const einvar wird, aus Pfeilfunktionen gewöhnliche Funktionen und aus Template-Strings eine Kette von Additionen. Wer einmal gesehen hat, was ein Compiler wirklich anstellt, versteht danach besser, warum bestimmte Dinge langsam sind.

Ebenfalls lehrreich: Die Typen sind im Ergebnis vollständig verschwunden. Kein: string, kein interface. Sie existieren nur während der Prüfung.

Probleme

Jede Meldung des Compilers mit Zeile, Spalte und der offiziellen Fehlernummer (etwaTS2322). Ein Klick auf eine Meldung springt im Editor genau an die Stelle und markiert sie. Die Fehlernummern sind übrigens gut zu wissen: Sie lassen sich wörtlich suchen und führen zu präziseren Ergebnissen als der Fehlertext.

Konsole

Alles, was dein Code über console.log ausgibt. Objekte werden lesbar aufgeschlüsselt, Laufzeitfehler erscheinen rot mit ihrer Meldung.

Typfehler halten die Ausführung nicht auf

Wenn dein Code Typfehler hat, läuft er hier trotzdem — und das ist kein Fehler des Werkzeugs, sondern das echte Verhalten von TypeScript. Die Typen werden beim Übersetzen entfernt, das erzeugte JavaScript ist gültig, und der Browser führt es aus.

Auf der Kommandozeile ist es genauso: tsc schreibt die.js-Dateien auch dann, wenn es sich beschwert hat — es sei denn, du setzt ausdrücklich noEmitOnError. Das ist eine der nützlichsten Erkenntnisse für Einsteiger: TypeScript ist ein Ratgeber, kein Türsteher. Es sagt dir, wo etwas nicht zusammenpasst; ob du hörst, bleibt dir überlassen.

Vier Dinge, die sich hier besonders gut ausprobieren lassen

1. „strict" aus- und wieder einschalten. Nimm eine Funktion ohne Typangaben am Parameter und beobachte, wie die Meldung TS7006 erscheint und verschwindet. Das zeigt anschaulich, wie viel von TypeScripts Nutzen an dieser einen Option hängt.

2. any gegen unknown tauschen. Mitany nimmt der Compiler alles hin, auch das, was zur Laufzeit abstürzt. Mitunknown verlangt er erst eine Prüfung. Der Unterschied ist in fünf Zeilen sichtbar und erklärt sich von selbst.

3. Narrowing beobachten. Schreib einen Union-Typ und frag in einemif ein Feld ab. Im einen Zweig kennt der Compiler danach andere Eigenschaften als im anderen — dass er das selbstständig mitdenkt, ist eine der elegantesten Eigenschaften der Sprache.

4. Utility Types anwenden. Omit, Partial,Pick, Readonly: aus einem Interface mehrere ableiten, statt sie von Hand zu kopieren. Fahr im Editor über den abgeleiteten Typ, und du siehst, was dabei herauskommt.

Häufige Fragen

Was ist ein TypeScript Playground?

Eine Umgebung, in der du TypeScript schreiben, sofort auf Typfehler prüfen und das erzeugte JavaScript ansehen kannst — ohne Node.js, ohne npm install, ohne Projektordner. Du tippst, der Compiler antwortet. Genau das, was du sonst mit einem lokalen tsc-Aufruf machst, nur ohne Einrichtung.

Wird mein Code an einen Server geschickt?

Nein. Der TypeScript-Compiler selbst wird in deinen Browser geladen und läuft dort in einem Web Worker. Deine Eingabe verlässt das Gerät nicht, es gibt keinen Kompilier-Dienst dahinter und keine Anmeldung. Sobald der Compiler einmal geladen ist, funktioniert das Werkzeug sogar ohne Internetverbindung weiter.

Welche TypeScript-Version läuft hier?

TypeScript 6.0.3 — die letzte Fassung, die als JavaScript-Bibliothek ausgeliefert wird und deshalb im Browser laufen kann. Ab Version 7 ist der Compiler ein nativer Go-Port und wird als plattformspezifische Programmdatei verteilt; die lässt sich in keiner Webseite ausführen. Die genaue geladene Version steht unter dem Editor, direkt aus dem Compiler ausgelesen.

Warum lädt der Compiler erst beim ersten Klick?

Weil er rund 2,1 MB komprimiert (Compiler und Typdefinitionen zusammen) groß ist. Das ungefragt bei jedem Seitenaufruf zu laden, wäre unhöflich gegenüber jedem, der nur den Text lesen will — besonders im Mobilfunknetz. Deshalb startet der Ladevorgang erst, wenn du auf „Ausführen" klickst oder ernsthaft zu tippen anfängst.

Was bedeutet die Option „strict"?

Sie schaltet die strengen Prüfungen ein: keine impliziten any-Typen, Rücksicht auf null und undefined, striktere Funktionssignaturen. Fast alle ernsthaften Projekte laufen mit strict, weil TypeScript ohne diese Option einen großen Teil seines Nutzens verliert. Schalte sie ruhig aus, um den Unterschied zu sehen — derselbe Code liefert dann deutlich weniger Meldungen.

Warum läuft mein Code trotz Typfehler?

Weil TypeScript-Typen zur Laufzeit nicht existieren. Der Compiler entfernt sie und erzeugt gewöhnliches JavaScript — auch dann, wenn er sich vorher beschwert hat. Genau so verhält sich tsc auf der Kommandozeile ohne die Option noEmitOnError. Ein Typfehler ist eine Warnung an dich, kein Riegel für den Browser.

Kann ich meinen Code teilen?

Ja, über „Link teilen". Der Code wird dabei in die Adresse selbst kodiert, nicht auf einem Server gespeichert. Wer den Link öffnet, sieht deinen Stand — und wir sehen ihn nicht. Bei sehr langem Code stößt die Adresszeile allerdings an ihre Grenze; dann sagt das Werkzeug Bescheid, statt einen kaputten Link zu erzeugen.

Wofür ist die Option „Ziel" (target) gut?

Sie legt fest, für welche JavaScript-Generation übersetzt wird. Auf ES2022 bleibt moderner Code weitgehend so, wie du ihn geschrieben hast. Stellst du auf ES5, siehst du, was früher nötig war: aus const wird var, aus Pfeilfunktionen werden gewöhnliche Funktionen, aus Template-Strings wird Zeichenkettenaddition. Das ist die anschaulichste Art zu verstehen, was ein Compiler eigentlich tut.

Ersetzt der Playground eine echte Entwicklungsumgebung?

Nein, und das soll er auch nicht. Hier fehlen mehrere Dateien, Imports aus npm-Paketen, eine tsconfig.json und alles, was ein echtes Projekt ausmacht. Der Playground ist zum Lernen, Ausprobieren und Vorführen gedacht — für ein Projekt gehört TypeScript lokal installiert.

Weiterlesen