JavaScript Formatter / Minifier

How to Use the JavaScript Formatter

1. Paste your source into the input pane. Plain JavaScript, TypeScript, ES modules, CommonJS, or a minified bundle downloaded from a CDN are all accepted.
2. Choose an indent: 2 spaces (the Airbnb and Prettier default), 4 spaces (older Node conventions), or tabs.
3. Press Format to break the source across lines with proper indentation around braces and brackets, or Minify to collapse the code into the smallest byte-count equivalent.
4. Copy or keep iterating. The output pane retains the last result so you can toggle between Format and Minify on the same buffer without losing state.

How the Formatter Works

The implementation uses pattern-based transformations rather than a full ECMAScript parser. It tracks three contexts while scanning: inside a string literal (single, double, or template), inside a regular expression literal, and inside a block or line comment. Outside those regions, an opening brace or bracket increments an indent counter and inserts a newline; a closing brace or bracket decrements and emits a newline before it. Semicolons at statement boundaries trigger newlines so each statement ends up on its own line.

The minifier does the opposite: runs of whitespace collapse to a single space or are removed where JavaScript's automatic semicolon insertion (ASI) rules permit, and all line and block comments are stripped. Because the formatter is not a real parser, it does not rename identifiers, dead-code eliminate, or apply the dozens of size-saving transforms a production tool like Terser or esbuild would. Its job is readability round-trips, not build-time optimisation. That trade-off also means the tool tolerates TypeScript, JSX, decorators, and stage-3 proposals that would break a strict ECMAScript parser.

Typical Scenarios

• Reading a minified vendor script from a node_modules bundle to locate the source of a production error.
• Preparing a code sample for a blog post, README, or internal wiki where indentation must match the project style guide.
• Stripping comments from a snippet before sharing it externally to remove TODOs or internal Jira IDs.
• Normalising the output of a codegen tool (Nexus, GraphQL Code Generator) whose whitespace varies between runs.
• Compressing an inline analytics snippet that will be embedded into a <script> tag on a page with no build step.
• Converting between tabs and spaces quickly when you clone a repo with a foreign editor config.

Pitfalls You Should Know About

• ASI hazards. JavaScript inserts semicolons at line breaks only in certain contexts. Minifying code that relies on implicit semicolons and starts a line with [, (, or / can change its meaning. If your source is semicolon-less (Standard.js style), add a leading semicolon to those lines before minifying.
• Template literals with nested expressions. ${'${'}...} interpolations are preserved verbatim because the tokenizer tracks template-literal depth, but deeply nested templates may receive unusual indentation inside the output.
• Regex vs. division. Without a real parser, a / b and a / b /g can be ambiguous. The tool uses simple heuristics (previous token must be a value for division) and handles the common cases, but obscure code can misread a regex.
• JSX. JSX survives a round-trip but does not receive React-aware indentation (attributes on separate lines, self-closing at the end). Use Prettier for production JSX.
• Source maps. Minifying here does not produce a source map. If you need stack traces to point at original lines, minify during your build step with Terser and keep the .map file.

JavaScript Language Background

JavaScript is standardised as ECMAScript, published annually by Ecma International as ECMA-262. The current edition at time of writing is ES2024. The language is whitespace-insensitive except for a handful of rules: automatic semicolon insertion at specific token boundaries, restricted productions (for example, you cannot put a newline between return and the returned expression), and the newline-sensitive behaviour of ++ and --. That is why this tool avoids rewriting anything that might affect ASI and why the minifier keeps semicolons rather than relying on implicit ones. TypeScript is a superset maintained by Microsoft; its type annotations are erased before execution and are therefore safe to preserve as plain text by a text-level formatter.

Compatibility with Prettier Defaults

The online JavaScript formatter targets Prettier's default style so that output pasted back into a Prettier-governed repo stays idempotent on the next lint pass. Those defaults are: 2-space indentation, semicolons after statements, double quotes only when the string contains a single quote (otherwise single quotes), trailing commas in multi-line arrays and objects, and an 80-character print-width hint for line breaks. Keeping those defaults matches what npx prettier --write would produce with a zero-config setup, which is the most common configuration across open-source repos. If your team overrides one of these in a .prettierrc, run Prettier locally after this tool to reconcile the two.

How It Differs from Prettier, ESLint, and Terser

Prettier builds a full AST with Babel and reprints code according to an opinionated style guide - handling line-length limits, trailing commas, and consistent quotes. Run Prettier in your repo; it always produces a better result for serious formatting. eslint --fix runs rule-driven auto-fixes (unused imports, var-to-let). Terser or esbuild --minify does semantic minification: mangles identifiers, drops dead branches, folds constants. Those require a real parser and trust in the code's correctness. This in-browser tool is for the specific case where you cannot (or do not want to) install any of those - reading a single minified snippet, prepping a one-line example for documentation, or quickly shrinking a throwaway file.