JavaScript Formatter & Minifier

JavaScript formatters have been a category of their own ever since Prettier put opinionated formatting on the map in 2017 and changed how teams thought about code style. The argument 'just run Prettier' is now the default answer to bikeshedding about indentation, quote style, or trailing commas; the broader principle — that formatting should be a tool's responsibility, not a human's — has bled into every modern codebase. This tool is the ad-hoc, paste-and-format counterpart to that workflow: when you have a snippet from somewhere (a Stack Overflow answer, a minified bundle, a dynamically generated function body, an in-browser DevTools paste) and you want it formatted right now without setting up a project or installing tooling, this is the answer.

The formatter implementation uses js-beautify's JavaScript mode, which is the same engine that powers most editor 'beautify' commands. It handles the full surface of modern JavaScript: ES modules, async/await, generators, classes, destructuring, default parameters, rest/spread, optional chaining (?.), nullish coalescing (??), logical assignment (||=, &&=, ??=), template literals (including tagged templates), private class fields (#field), top-level await, dynamic import(), and the various combinations of these. JSX is supported, with the right indentation for nested children and attributes. Configuration knobs: indent size (2 / 4 / tabs), brace placement (collapse, end-expand, expand), line wrapping, and trailing comma handling. The defaults follow the most common style guides; switch them if your team's conventions differ.

Minification is the part that needs an honest disclaimer. Real production minifiers (Terser, esbuild's minifier, SWC's minifier) do much more than collapse whitespace: they rename local variables to single letters, inline single-use functions, fold constant expressions, dead-code-eliminate unreachable branches, and apply hundreds of other transformations that compound to 60-80% byte reduction on typical bundles. The minifier here is a whitespace-only collapse: it strips comments (// and /* */), drops blank lines, removes whitespace around punctuation where it is safe to do so, and concatenates the result. The byte savings are typically 10-20% for hand-written code and lower for already-formatted code. This is enough for a fast smoke test or a tiny inline script, but for production you should still run Terser or esbuild. The yellow warning banner in the UI says exactly that — we are not pretending to compete with the real minifiers.

The whitespace-only minifier earns its keep in a few real cases. First, embedded scripts inline in HTML where pulling in a build pipeline is overkill — a 200-byte initialization script in a static page benefits from minification but does not need Terser-level optimization. Second, inline event handlers in HTML attributes that you want to compact for size. Third, ad-hoc obfuscation (very lightweight — anyone can re-format the output, so it is not a security mechanism, just a discouragement). Fourth, fitting code into a size-constrained container (a <script> tag in a CMS field with a max length, an inline service-worker template, etc.). For anything beyond these cases, run a real minifier in your build.

Modern syntax handling is where naive JavaScript formatters fall apart, and where this implementation invests effort to be correct. Template literals with embedded expressions (`Hello ${name}`) need to track the brace depth inside ${} so that a } inside an expression is not treated as the end of a code block. Regex literals (/pattern/flags) need to be distinguished from division by context — the same character / can be a divisor or the start of a regex depending on what came before. Tagged templates (sql`SELECT ...`) need to preserve the whitespace inside the template because tag functions sometimes parse the literal contents (sql tags are a common case). The formatter and minifier handle these cases through a state machine that tracks parser context. Most of the time you do not need to think about this; it just works.

JSX is a special case because it is HTML-shaped syntax embedded inside JavaScript. The formatter indents JSX children at one level deeper than the parent expression, wraps long attribute lists onto multiple lines, and preserves the literal whitespace inside string children that affects rendering. JSX expressions ({user.name}) format like any other expression. The minifier is more conservative around JSX than around plain JavaScript — JSX whitespace can be semantically significant (a space between two text children renders, a newline-only between them often does not), so the minifier preserves more whitespace inside JSX than it does in surrounding code. This conservatism costs a few bytes but avoids breaking the rendering.

TypeScript is mostly handled by the formatter. The TS-specific syntax (type annotations, interfaces, type aliases, generics, decorators) formats correctly because the underlying parser understands it; the configuration knobs are the same as for plain JS. The minifier strips comments and whitespace as for plain JS — note that it does not strip the type annotations themselves, which the TypeScript compiler does. To strip TS to plain JS for deployment, use tsc, esbuild, or swc. This tool is for ad-hoc paste-format-copy work, not a compiler replacement.

Common pitfalls worth flagging. First, automatic semicolon insertion (ASI) — JavaScript's rule about where a semicolon can be implicitly inserted is real and occasionally surprising; the formatter does not insert semicolons that are not in your source, so if your code relies on ASI in a way that breaks under a different formatter, this tool will not 'fix' that. Second, comments inside expressions — JSDoc comments (/** ... */) are preserved by the formatter, but inline-expression comments (a + /* hex */ b) can produce confusing output if they are inside a multi-line expression. Third, very long single expressions — the formatter will not break a 500-character chained expression into multiple lines on its own; if you want that, refactor manually first. Prettier handles this case better than js-beautify, but is harder to run as a paste-and-format tool.

Performance is essentially instant for typical snippets. A 50KB JavaScript file formats in well under 100ms; a 1MB file takes a few hundred ms. The minifier is faster than the formatter (less work to do). For genuinely huge inputs (multi-megabyte minified bundles), the browser tab will struggle, and you should use command-line tools instead — node + js-beautify-cli for formatting, terser-cli or esbuild for minification. The 99% case of everyday work is well within the browser implementation's range.

Privacy is the same model as the rest of our tools: nothing is uploaded, nothing is logged, everything runs in your browser. The JavaScript you paste — including any embedded API keys, internal URLs, or pre-release logic — never leaves your device. You can verify by opening the network tab during formatting — no outbound requests beyond the static page assets. This matters when the code contains sensitive material that you would not want flowing through a third-party server. Many online JavaScript formatters and minifiers upload the source to a server for processing, which is often forbidden by corporate policies; this tool does not.

The tool pairs with the rest of the developer suite. The HTML Formatter handles the markup that scripts run inside; the CSS Formatter is the third leg of the front-end formatting trio. The JSON Viewer is useful when working with JSON data inside JavaScript; the JSON to TypeScript generator turns JSON samples into types you can import. The Regex Tester is the right place to debug regex literals before pasting them into your code. For documentation work, the Markdown ↔ HTML Converter and Schema.org JSON-LD Builder handle the related formats.

Workflow tip: when reviewing minified bundles in DevTools, paste the chunk into this formatter to make it readable, but be aware that the formatted output is not source-mapped — variable names are still single letters, control flow is still inverted by the optimizer, and scope is still flattened. To recover something close to the original source, you need a source map, which is a separate file the build pipeline produces. The formatter makes the syntax navigable; only the source map gives you back the original names. For production debugging, source maps are the right tool; for casual inspection, the formatter is enough.