Formatted JavaScript appears here
Paste JS and click Beautify β or enable Live format// format and indent JavaScript for maximum readability
Format and beautify JavaScript instantly. Configurable indent size, brace style, quote normalization, semicolon insertion, and syntax-highlighted output with line numbers. Free, no sign-up.
Formatted JavaScript appears here
Paste JS and click Beautify β or enable Live formatPaste any JavaScript β minified production code, a copied snippet from DevTools, a bundled file, or messy auto-generated output. The formatter handles both modern ES2024 and legacy code.
Choose your indent size (2, 4, or tab), brace style (collapse keeps { on the same line; expand puts it on a new line), and quote and semicolon preferences.
The syntax-highlighted output with line numbers appears on the right. Click Copy to grab the plain formatted JS, or Download to save it as a .js file.
JS Beautifier formats and re-indents JavaScript source code for human readability. It handles the full JavaScript grammar including modern ES2024 syntax β arrow functions, template literals, destructuring, optional chaining, and more β and outputs syntax-highlighted code with line numbers, entirely in your browser, free.
JavaScript beautification (also called pretty-printing or formatting) adds consistent indentation and line breaks to JavaScript source code to make it readable. Minified JavaScript has all unnecessary whitespace removed for compact delivery β typically resulting in one or very few long lines. Beautification reverses this, making the code structure visible and the logic understandable without changing how the code executes.
"Collapse" style (also known as K&R or 1TBS) keeps the opening brace on the same line as the statement: if (x) {. This is the most common style in JavaScript and is what Prettier uses by default. "Expand" style (also known as Allman style) places the opening brace on its own line. Both are valid; the choice is purely a team convention. Collapse is strongly preferred in the JavaScript community.
Yes, for reading and analysis purposes. The beautified code is functionally identical to the minified version. However, minified code is often also mangled β variable names are shortened to single characters β so the logic may be harder to follow even after formatting. The formatter cannot reverse mangling; it only restores whitespace and indentation structure.
The formatter supports modern JavaScript (ES2024) including: arrow functions, template literals, destructuring assignment, spread and rest operators, optional chaining (?.), nullish coalescing (??), async/await, class syntax, generators, dynamic imports, logical assignment operators, and all standard ES6+ features. It also handles older CommonJS-style code with require() and module.exports.
Changing between single and double quotes does not affect JavaScript execution β both are semantically equivalent for string literals. Template literals (backtick strings) are kept as-is, since they support interpolation and multi-line strings that single/double quotes cannot replicate. The quote normalisation in this tool only changes simple string delimiters, not template literals.
This is a team style choice. Semicolons are optional in most positions because of JavaScript's Automatic Semicolon Insertion (ASI) rules. Many style guides (Airbnb, Google) require semicolons; others (StandardJS) omit them. The key is consistency: don't mix styles in the same codebase. If you're using a linter like ESLint with a shared config, let that config decide rather than changing them manually.
Minified JavaScript is optimised for delivery, not for reading. A production bundle from webpack or Rollup strips all whitespace, collapses all statements to single lines, and sometimes mangles variable names to single characters. Reading minified code directly is nearly impossible for any non-trivial script. A JavaScript beautifier restores the formatting, making the code structure legible β the same code executes identically, but the indentation and line breaks make the logic follow-able.
JavaScript formatting is most useful when debugging, auditing, or learning from third-party code. When a browser's network tab shows a script loading slowly, downloading and formatting it reveals what it does. When a third-party widget adds unexpected behaviour, formatting its source exposes the event listeners and network calls. When a legacy codebase has no consistent style, formatting it is the first step toward normalisation before introducing a linter.
The most common brace style in JavaScript is K&R (Kernighan and Ritchie), where opening braces appear at the end of the statement line. This is what virtually every major JavaScript style guide prescribes β ESLint's recommended config, Prettier's default, Airbnb's style guide, and Google's style guide all use the same-line opening brace. The Allman style (opening brace on its own line) is common in C-family languages but rare in JavaScript. This formatter supports both; choose the one that matches your project's existing conventions.
JavaScript supports single quotes, double quotes, and template literals (backticks) interchangeably for simple strings. Prettier defaults to double quotes. StandardJS uses single quotes. The choice is arbitrary and should be governed by your linter configuration. Template literals are a special case β they support embedded expressions and multi-line strings, so this formatter always preserves them as-is regardless of the quote style setting.
JavaScript's Automatic Semicolon Insertion (ASI) rules mean semicolons are optional at the end of most statements. The spec defines specific line terminators where a parser inserts a semicolon automatically. In practice, ASI behaves predictably for well-structured code, but there are several well-known edge cases β lines starting with [, (, or / after a line ending without a semicolon β where ASI can produce unexpected results. For this reason, many teams require explicit semicolons even though they are optional.