JS Formatter

JavaScript Formatter — Beautify and Indent Your JS Code Online

Opening a JavaScript file and finding a single continuous line stretching across tens of thousands of characters is a uniquely frustrating experience. It happens when minified production bundles get committed to repositories by mistake, when library files are copied directly into a project without the original source, or when a build tool generates output that nobody thought to format. Whatever the cause, the result is code you cannot read, cannot debug, and cannot confidently modify. A JavaScript formatter takes that dense block and restructures it with proper indentation, logical line breaks, and clear block separation — making the code navigable without changing a single character of its logic.

This tool runs entirely in your browser. Paste your code or upload a file, format it, and copy or download the result. It works with modern ES2020+ syntax including arrow functions, async/await, destructuring, optional chaining, template literals, class syntax, and ES module import/export statements. Whether you're dealing with a minified vendor library, code pasted from an online example, or a file that lost its formatting in a merge conflict, this tool gets it back to a readable state in seconds.

Why a JavaScript Formatter Needs to Understand the Language

A naive text reformatter that simply looks for { and adds a newline after it will break on real JavaScript. Curly braces appear inside strings, template literals, regex patterns, and object literals in ways that a string scanner cannot correctly interpret. A proper JavaScript formatter parses the code into an Abstract Syntax Tree (AST) — a structured representation of every syntactic element. Functions become function nodes, if-else blocks become conditional nodes, object literals become expression nodes with property children. Arrow functions, class declarations, import statements, and destructuring patterns are all represented as correctly typed nodes in the tree.

Once the AST is built, the formatter walks it and serializes it back to text with consistent indentation and spacing at every node boundary. This approach correctly handles the patterns that trip up naive tools: object literals nested inside function calls, ternary expressions inside template literals, destructuring in function parameters, and arrow functions returning object literals wrapped in parentheses. The AST-based approach is also what makes it possible to format code that spans multiple lines without breaking anything — the formatter understands the logical structure, not just the text.

Arrow Function Formatting and Modern Syntax

Arrow functions introduced formatting questions that didn't exist with traditional function declarations. Should a single-parameter arrow function keep its parentheses? Does the body go on the same line or the next? When does an arrow function body need braces versus an implicit return?

The practical conventions: single-parameter arrows typically drop parentheses in casual code (x => x * 2) but keep them in codebases that enforce consistency ((x) => x * 2). Prettier defaults to dropping them for single parameters but this is configurable. Multi-line arrow function bodies almost always use braces and an explicit return. Arrow functions that return object literals need parentheses around the entire expression: () => ({ key: value }) — without them, JavaScript interprets the braces as a function body, not an object literal. A formatter handles this correctly, but understanding the pattern helps when reading the formatted output.

Async/await style: The async keyword appears before the function keyword or arrow: async function getData() or const getData = async () => {...}. Formatters place await at the same indentation level as the code around it. The formatted output makes the asynchronous flow linear and readable — what used to be deeply nested callback chains become flat, sequential-looking code.

The Semicolons Debate and Other Formatting Conventions

JavaScript has no official formatting standard. Unlike Python (where PEP 8 defines a widely accepted style), the JavaScript community has converged on tool-enforced consistency rather than a single document. The debate over trailing semicolons is the most visible example: one camp argues that explicit semicolons prevent ambiguity and make code behavior predictable; the other camp points out that ASI (Automatic Semicolon Insertion) handles most cases and omitting semicolons produces cleaner-looking code.

The practical answer is that either convention works fine — what matters is consistency within a project. Prettier makes this a non-decision: you configure it once (semicolons or no semicolons) and every file in the project follows that rule automatically. The same applies to single vs. double quotes, trailing commas, bracket spacing, and arrow function parentheses. The "Standard" style guide (no semicolons) and the Airbnb style guide (semicolons required) are both perfectly valid choices.

Other conventions worth standardizing: 2-space indentation (the dominant choice in the JavaScript community, used by Airbnb, Google, and StandardJS style guides), single quotes for strings (slightly less visual noise and avoids escaping in JSX), trailing commas in multiline constructs (cleaner diffs when adding new items, and safer for ES5 environments that require them), and arrow functions for callbacks (shorter syntax, lexical this binding that eliminates the const self = this pattern).

Minification vs. Formatting: Know the Difference

Minification and formatting are opposite operations on the same code, and confusing them is a common source of frustration. Formatting adds whitespace, indentation, and line breaks to make code readable. Minification strips all of that away to reduce file size for production delivery.

Minifiers like Terser and UglifyJS do more than remove whitespace — they also shorten variable names, eliminate dead code, and apply algebraic simplifications (like converting x * 2 to x << 1). Formatting does none of these things. A formatter only touches whitespace and line structure. The two tools serve different purposes in the development lifecycle: format during development, minify for deployment.

A common workflow: you format code in your editor (Prettier on save), commit formatted code to version control, and the build pipeline minifies it for the production bundle. Users download the minified version; developers work with the formatted version. If you're staring at a minified file and need to understand it, run it through this formatter to get the structural formatting back. You won't get original variable names back (that's deobfuscation, a different problem entirely), but you will get readable block structure, indentation, and line breaks.

Module and Import/Export Formatting

ES modules introduced import/export syntax that needs consistent formatting to stay readable. The conventions that have emerged: imports go at the top of the file, one per line, organized in groups (external packages first, then internal modules, then relative imports). Named imports use braces on the same line for short lists and multi-line for longer ones.

Prettier handles the structural formatting — where to break lines, when to use multi-line syntax. But import ordering is a formatting-adjacent concern that Prettier does not handle. Tools like eslint-plugin-import and @trivago/prettier-plugin-sort-imports fill that gap, sorting imports alphabetically by path, grouping them by type, and removing unused imports automatically.

Prettier + ESLint: The Standard Professional Setup

The two dominant tools in the JavaScript ecosystem serve different purposes and are designed to work together:

Prettier is an opinionated formatter. It handles indentation, semicolons, quote style, line length wrapping, and bracket spacing. It supports very limited configuration by design — the goal is that all Prettier-formatted code looks the same regardless of who wrote it. It works with JavaScript, TypeScript, JSX, CSS, HTML, JSON, Markdown, and more. Prettier's opinionated nature is its strength: it eliminates formatting debates by making them non-negotiable.

ESLint is a linter that checks for code quality: unused variables, potential runtime errors, deprecated APIs, security concerns, and violations of team coding rules. ESLint can apply some formatting rules, but teams commonly configure it to defer all formatting to Prettier using eslint-config-prettier, which disables ESLint's formatting-related rules to avoid conflicts. Running both tools with overlapping rules leads to inconsistent output and confusing errors — the eslint-config-prettier package eliminates that by explicitly turning off every ESLint rule that Prettier handles.

The standard setup: Prettier for formatting + ESLint for quality + pre-commit hooks (via Husky and lint-staged) to run both automatically before every commit. This ensures code entering version control is always consistently formatted and clean, regardless of individual editor configurations. New team members get the same formatting as everyone else from their first commit.

Common Formatting Pitfalls in JavaScript

Template literal indentation: Multi-line template literals with embedded expressions can produce confusingly indented output. The formatter handles the outer structure, but the content inside ${} expressions follows expression-level formatting rules, not line-level rules.

Chained method calls: Long method chains (.then().then().catch()) can be formatted in two styles: one method per line (Prettier's default for long chains) or all methods on one line if they fit. If your codebase has a preference, configure Prettier's experimentalTernaries or chain-breaking behavior accordingly.

Object destructuring in function parameters: A function like function processUser({ name, age, email }) { may need to break across multiple lines depending on line length. Prettier handles this automatically, but the formatted result can sometimes be harder to read than the original if the destructuring pattern is complex. In those cases, extracting the destructuring to a separate line often improves clarity.

Frequently Asked Questions About JavaScript Formatting