JavaScript-Formatierungstool

JavaScript Eingabe

Einrückungsbreite:

Ausgabeergebnis

Zeilen: 1Zeichen: 0Bytes: 0

Zeilen: 1Zeichen: 0

Was ist JavaScript-Formatierung?

Der JavaScript-Formatter bringt JavaScript-Code in eine einheitliche, gut lesbare Form. Er strukturiert Einrückung, Zeilenumbrüche, Blöcke, Objektliterale, Arrays, Funktionsaufrufe und verschachtelte Ausdrücke so, dass Logik und Datenfluss schneller erkennbar werden. Das hilft bei Debugging, Code-Reviews, Lernbeispielen, kopierten Snippets und komprimierten Dateien. Formatierung ist jedoch keine statische Analyse: Sie behebt keine Laufzeitfehler, erkennt nicht jede unsichere Abhängigkeit und entscheidet nicht, ob asynchrone Logik korrekt ist. Für echte Projekte sollte das Ergebnis mit ESLint, Prettier oder den vorhandenen Teamregeln zusammenpassen, damit Stiländerungen nicht die inhaltliche Änderung überdecken. Besonders bei produktiven Daten oder Codebasen sollte das Ergebnis anschließend mit Parser, Tests oder Projektregeln geprüft werden.

Anleitung

So geht's

JavaScript-Code im linken Eingabefeld einfügen oder eingeben
Einrückungsgröße, Anführungszeichen-Stil und Semikolon-Einstellungen auswählen
Auf ‚Formatieren‘ klicken, um den Code zu verschönern, oder ‚Validieren‘, um die Syntax zu prüfen
Ergebnisse rechts einsehen (mit Syntaxhervorhebung)
Auf ‚Kopieren‘ klicken, um in die Zwischenablage zu kopieren

Optionen

EinrückungsgrößeZwischen 2 Leerzeichen, 4 Leerzeichen oder Tabulator-Einrückung wählen

AnführungszeichenAuf einfache oder doppelte Anführungszeichen vereinheitlichen oder Original beibehalten

SemikolonsImmer hinzufügen, entfernen oder beibehalten

Tastenkürzel

Ctrl + EnterFormatieren
Ctrl + Shift + CErgebnis kopieren

Hinweise zu JavaScript

Das Formatieren beweist nicht die Korrektheit zur Laufzeit. Führen Sie Tests oder Browser-Checks erneut aus, wenn Sie JavaScript geändert haben, das von automatischer Semikolon-Einfügung oder Build-Transformationen abhängt.
Beim Validieren von eingefügtem Code bedenken Sie, dass die Parser-Unterstützung des Browsers von Ihrer Ziel-Laufzeitumgebung oder Bundler-Konfiguration abweichen kann.

Anwendungsfälle

Browser-JavaScript wieder lesbar machenWenn ein Bookmarklet, Analytics-Snippet, Console-Helfer oder kopiertes Inline-Skript als eine einzige lange Zeile vorliegt, stellt der Formatter Zeilenumbrüche um Blöcke und Anweisungen wieder her. Die Syntaxprüfung nutzt die Browser-JavaScript-Engine, um Fehler zu erkennen, bevor der Code wiederverwendet wird.

Kleine Skripte für Einbettung komprimierenFür kurze JavaScript-Schnipsel, die in HTML, CMS-Einstellungen oder Tag-Manager-Feldern eingebettet werden müssen, entfernt der Komprimierungsmodus Kommentare und unnötige Leerzeichen. Ein schneller lokaler Workflow für Deployment-Snippets, bei dem ein vollständiger Bundler überdimensioniert wäre.

Beispiele vor dem Teilen prüfenBevor ein Reproduktionsbeispiel an Kollegen gesendet oder eine Antwort gepostet wird, kann der Code eingefügt werden, um die Syntax zu prüfen und das Layout zu normalisieren. Das Tool eignet sich am besten für Browser-kompatible JavaScript-Snippets anstelle von TypeScript, JSX oder projektweiten Transformationen.

Minifizierte Vendor-Skripte für Audit aufbereitenEin ausgeliefertes min.js-Bundle erweitern, um obfuskate Logik, tote Verzweigungen oder unerwartete Netzwerkaufrufe zu prüfen, bevor es in einen Tag-Manager aufgenommen wird. Die Prüfung mit der Quellkarte (Source Map) kombinieren, sofern verfügbar, da Variablennamen im minifizierten Datei nicht allein durch Formatierung rückgängig gemacht werden können. Besonders achten auf return-Anweisungen, Template-Literale und verkettete .then()-Aufrufe: Die automatische Semikolon-Einfügung (ASI) nach ECMA-262 §11.9.1 bedeutet, dass der Formatter nicht direkt vor einer Anweisung mit (, [, `, +, - oder / umbrechen darf, da sich sonst die Programmatik stillschweigend ändert.

Formatierte Ausgabe mit Prettier-Standard vergleichenEin Snippet durch diesen Formatter und durch die Prettier-Konfiguration des Projekts laufen lassen, um Unterschiede bei Leerzeichen um Arrow-Funktionen, Ternary-Ausdrücke und verkettete Aufrufe zu erkennen. Als schneller Plausibilitätscheck gedacht, nicht als Ersatz, da Prettier JSX, TypeScript und Import-Reihenfolgen auf Weisen handhabt, die der eigenständige Browser-Formatter nicht unterstützt. Prettiers printWidth von 80 vs. 100 vs. 120 verändert, wo lange verkettete Aufrufe umbrechen, und der Wechsel zwischen einfachen und doppelten Anführungszeichen rendert String-Literale neu, ohne zugehörige Kommentare zu verändern; JSX-Attribute müssen jedoch bei doppelten Anführungszeichen bleiben, da Browser sie als HTML parsen, was dieser eigenständige Formatter nicht versteht.

Technisches Prinzip

Ein JavaScript-Pretty-Printer ist eine dreistufige Pipeline, die auf der ECMA-262-Grammatik basiert: Ein Lexer erzeugt einen Token-Stream aus IdentifierName, NumericLiteral, StringLiteral, TemplateHead/Middle/Tail, Punctuator, Keyword und LineTerminator; ein Parser baut einen ESTree-kompatiblen AST (die Struktur, die von @babel/parser, acorn und esprima verwendet wird); ein Printer durchläuft den Baum und gibt Text nach Regeln aus, die von Einrückungsbreite und Ziel-Druckbreite gesteuert werden. Prettier kompiliert den AST in eine Doc-Zwischendarstellung, die aus den Primitiven group, indent, line und softline aufgebaut ist; anschließend wählt ein Layout-Algorithmus Umbruchpunkte, damit die Ausgabe in die printWidth (80, 100, 120) passt. ESLint --fix hingegen überschreibt Tokens direkt in der Originalquelle, erhält Kommentare aggressiver, wendet aber nur Regeln an, die sich für Autofix angemeldet haben. Der Printer darf nicht beliebig Zeilenumbrüche einfügen: ECMA-262 §11.9.1 Automatic Semicolon Insertion beendet eine Anweisung bei jedem LineTerminator, sofern das nächste Token keine Fortsetzung ist. Konkret: Ein Umbruch vor einer Zeile, die mit `(`, `[`, `` ` ``, `+`, `-`, `/` oder einem `++`/`--`-Token beginnt, ändert stillschweigend die Semantik; ein Zeilenumbruch direkt nach `return`, `throw`, `break`, `continue` oder `yield` fügt ein Semikolon ein und verwirft den Operanden. Template-Literale (Backticks) erhalten ihre inneren Bytes eins zu eins, einschließlich eingebetteter `${}`-Ausdrücke, deren Inneres als JS neu formatiert wird, deren umgebender Whitespace jedoch nicht. Kommentare werden über leading/trailing/innerComments-Arrays an benachbarte AST-Knoten gebunden, sodass sie den Roundtrip überstehen. Lexing und Drucken sind jeweils O(n) über die Quelllänge mit kleiner Konstante; der Parser ist für wohlgeformten Code effektiv linear dank Single-Token-Lookahead in der ECMA-262 LR(1)-Grammatik. Standard-JavaScript-Parsing deckt nicht JSX, TypeScript-Typannotationen, Decorators oder Flow ab, die @babel/parser-Plugins oder @typescript-eslint/parser erfordern; die Ausführung von Plain-JS-Werkzeugen über eine .tsx-Datei lehnt `: type`-Annotationen ab. Source Maps (Source Map v3) können die ursprüngliche Zeilen-/Spalten-Zuordnung beibehalten, wenn ein Build-Schritt die Stack-Trace-Treue bewahren muss; Zeilenenden (LF vs. CRLF) werden beim Schreiben normalisiert, nicht beim Parsen.

Pipeline: Lexer (Token-Stream gemäß ECMA-262 §12) -> ESTree-AST (acorn/@babel/parser/esprima) -> Printer; Lexer und Printer sind O(n), Parser O(n) mit Single-Token-Lookahead.
ASI-Fallen aus ECMA-262 §11.9.1: Niemals eine Zeile vor einem Token umbrechen, das mit `(`, `[`, `` ` ``, `+`, `-`, `/` oder `++`/`--` beginnt, und niemals direkt nach `return`/`throw`/`break`/`continue`/`yield` umbrechen.
Prettier vs. ESLint --fix: Prettier senkt den AST auf eine Doc-IR (group/indent/line) und wählt Layouts, die in die printWidth (80/100/120) passen; ESLint --fix überschreibt Tokens direkt und wendet nur Regeln mit Fixer-Tag an.
Kommentarerhalt: leading/trailing/innerComments sind an AST-Knoten gebunden; JSDoc-Blöcke direkt oberhalb von Deklarationen bleiben angehängt, sodass der Printer sie nicht auf eine vorherige Anweisung verwaist.
Template-Literale (Backticks) werden bytegenau erhalten; nur das JS innerhalb von `${}` wird neu gedruckt. Regex-Literale und String-Literal-Quoting werden auf den gewählten Einzel-/Doppel-Anführungszeichen-Stil normalisiert, wobei `\`-Escapes neu berechnet werden.
Dialektabdeckung: Plain-JS-Parser lehnen JSX, TypeScript-Typen, Decorators und Flow ab; .tsx/.ts-Dateien benötigen @babel/parser-Plugins ['jsx','typescript','decorators-legacy'] oder @typescript-eslint/parser.
Ausgabenormalisierung: Zeilenenden werden gemäß Konfiguration als LF oder CRLF geschrieben (unabhängig von der Eingabe), Trailing-Comma-Regel wird auf mehrzeilige Arrays/Objekte/Aufrufe angewendet, und Source Map v3 wird ausgegeben, wenn die Toolchain die ursprüngliche Zeilen-/Spalten-Information beibehalten muss.

Beispiele

Vor der Formatierung

function greet(name){if(!name){return 'Hello, stranger';}const greeting=`Hello, ${name}!`;console.log(greeting);return greeting;}

Nach der Formatierung (2 Leerzeichen)

function greet(name) {
  if (!name) {
    return 'Hello, stranger';
  }
  const greeting = `Hello, ${name}!`;
  console.log(greeting);
  return greeting;
}

Nach der Minifizierung

function greet(n){if(!n)return"Hello, stranger";const e=`Hello, ${n}!`;return console.log(e),e}

FAQ

Welchen Stil verwendet der Formatter?

Die meisten Builds nutzen Prettier mit Standardeinstellungen: 80 Zeichen Zeilenbreite, Semikolons, doppelte Anführungszeichen, Einrückung mit 2 Leerzeichen und nachgestellte Kommas, sofern ES5-konform. Stell die Optionen um, wenn dein Projekt einen anderen Stil hat. Das Ergebnis ist bei gleicher Konfiguration deterministisch – gleiche Eingabe, gleiche Ausgabe.

Wird mein JS dabei ausgeführt?

Nein. Der Quelltext wird nur geparst und neu ausgegeben. Seiteneffekte, Netzwerkaufrufe oder Laufzeitfehler spielen keine Rolle – der Formatter führt das Skript niemals aus.

Werden Syntaxfehler korrigiert?

Nein. Der Parser weigert sich, ungültiges JavaScript zu formatieren, und zeigt dir, wo das Parsen scheitert. Behebe den Syntaxfehler zuerst; häufige Ursachen sind fehlende Klammern, ein fehlendes Semikolon nach einem return-from-IIFE oder Template Literals mit nicht passenden Backticks.

Werden JSX und TypeScript unterstützt?

Die meisten modernen Builds parsen JavaScript samt JSX und TypeScript-Syntax (.ts, .tsx). Der Formatter erkennt anhand des geparsten Codes, welche Syntax vorliegt. Wenn du nur in einfachem ES5 arbeitest, deaktiviere den TypeScript-Modus, um Falschmeldungen zu vermeiden.

Kann das Tool JS minifizieren?

Manche Builds bieten einen Minify-Modus (im Stil von Terser), der Variablen umbenennt, Whitespace entfernt und toten Code eliminiert. Die Ausgabe ist klein, aber nicht mehr lesbar. Nutze Minifizierung für Produktiv-Builds und Formatierung für die Code-Review.

Wird mein Code hochgeladen?

Nein. Parsen und Ausgabe laufen in deinem Browser über einen JavaScript-basierten Parser. Eingefügter Code wird nicht übertragen.

Warum sind meine Kommentare leicht verschoben?

Prettier und ähnliche Formatter hängen Kommentare an den nächstgelegenen AST-Knoten. Ein Kommentar zwischen zwei Funktionen kann im AST zur darunterliegenden Funktion gehören und wird entsprechend neu zugeordnet. Inline-Kommentare am Zeilenende bleiben meist exakt erhalten; freistehende Kommentare können sich verschieben.