JS Beautifier / Minifier

JS beautifier and the "minify" limit: why it should not replace a real minifier

What beautify does

Beautify re-indents by bracket level and expands one-line code into a readable form. It only changes whitespace and leaves the token sequence intact, so it is safe (provided the original code did not rely on automatic semicolon insertion edge cases — see below). Common uses:

• Understanding a slice of bundled output (variable names are mangled, but the structure is legible).
• Tidying a fragment copied from a minified file or a log.
• Unifying format before a commit.

The limit of "minify" here

Note the boundary: this tool provides whitespace-based minification, not the kind that terser or esbuild perform. The capability gap is large:

The key difference is in the last two rows. A professional minifier parses code into an AST (abstract syntax tree) and re-emits it, so it knows at the syntax level which whitespace is safe to drop; text-based minification can only guess with heuristic rules.

So the conclusion is clear: production code minification should use tools like terser, esbuild, or swc (bundlers usually build them in) — they are faster, more thorough, and support source maps. The value of this tool is quick handling of small fragments and a temporary preview of the effect; it is not a build step.

Risks around automatic semicolon insertion (ASI)

JavaScript has "automatic semicolon insertion": certain line breaks are interpreted as statement endings. This creates several classic traps and is exactly where text-level minification breaks most easily:

These rules mean deleting newlines is not always safe: merging two lines may change meaning. A correct minifier keeps the necessary newline or adds a semicolon at the statement end; a text-based implementation must be very careful at such edges. If behaviour changed after manual minification, suspect the newline here first.

So this tool protects string and template-literal contents during minification — the semicolon in "a ; b" and the newlines inside a template literal must not move. Even so, treat the minified result as a "size reference" and do not ship it to production.

Other formatting notes

• Regex literal versus division ambiguity. A / may be either division or the start of a regex, decided by context. Text-based implementations get confused by code containing regexes, producing wrong indentation.
• Newlines inside template literals must stay. Content between backticks is meaningful multi-line text; re-indenting it changes the string's value.
• Modern syntax. Optional chaining ?., nullish coalescing ??, destructuring, decorators, and similar syntax are also a challenge for text-based processors — they are not simple bracket nesting.
• Formatting does not check for errors. It will not tell you the code has a syntax error, nor will it add a missing semicolon or bracket. To verify the code runs, use a run-oriented tool or actually execute it.

How to use the tool

Paste code, click beautify for an indented version or minify for a compact version. It suits quickly tidying a fragment and eyeballing the post-minify size class. Processing runs locally in your browser, and code is never uploaded — important when it touches internal business logic.

To use it as a build step, switch to a dedicated minifier with source maps enabled, so production errors still map back to source positions.