Minify JavaScript whitespace and measure the size reduction

It keeps strings, template literals, regular-expression literals, operators, and identifier boundaries intact, while retaining line breaks where JavaScript automatic semicolon insertion can affect meaning. The result includes the compact source, original and minified UTF-8 byte counts, and the percentage saved. It is useful when you want predictable source compaction without identifier renaming, code rewriting, dependency installation, network access, or a complete bundling pipeline.

Compact source without rewriting the program

This capability focuses on one narrow job: removing comments and collapsing insignificant whitespace. It does not rename variables, fold constants, reorder expressions, alter property names, or transform modern syntax into an older language version. That limited scope makes the result easier to inspect and compare with the original. Send JavaScript in the javascript field, or use the accepted code or text alias, and receive compact JavaScript plus exact UTF-8 byte measurements. The scanner recognizes quoted strings, template literals, and regular-expression literals before it considers comment markers, so text such as a URL inside a string or a slash inside a regular expression is retained as program data. Spaces are reinserted only when adjacent tokens would otherwise merge into a different token. For example, two identifiers remain separated, while formatting around commas, braces, and most operators disappears. This is source compaction rather than obfuscation: names and program structure remain recognizable, and no hidden network service or nondeterministic model participates in the result.

Preserve JavaScript token and line-break semantics

Whitespace in JavaScript is often optional, but it is not universally meaningless. Joining two identifier characters can create a new name; joining two plus signs can create an increment operator; and removing a newline after return, throw, break, continue, or yield can change how automatic semicolon insertion interprets a statement. The minifier therefore tokenizes the input and makes boundary decisions between tokens instead of applying a global regular expression. It preserves significant line breaks for these automatic-semicolon-insertion cases and keeps potentially ambiguous operators apart. Comments are recognized only while the scanner is outside strings, template literals, and regular-expression literals. Delimiters are checked during the same pass: closing parentheses, square brackets, or braces must match the most recent opening delimiter. An unmatched or incorrectly nested delimiter produces an invalid-input error rather than suspicious output. Unterminated comments, strings, template literals, and regular expressions also fail clearly. This validation is deliberately structural rather than a full JavaScript parser, so the tool is best suited to syntactically valid source that needs conservative whitespace compaction.

Measure savings and integrate the deterministic result

The response reports original_bytes and minified_bytes using UTF-8 encoding, which is the relevant measurement for files transferred over HTTP or stored as ordinary web assets. It also reports reduction_percent rounded to two decimal places, making before-and-after checks simple in scripts, dashboards, or release notes. Because the algorithm is deterministic, the same input always returns the same output and byte counts. A build pipeline can submit generated source, write the returned javascript field to its artifact directory, and enforce a minimum reduction without installing a minifier package. A documentation system can compact inline examples while retaining meaningful tokens, and a lightweight deployment process can reduce hand-written utility scripts without introducing bundling or identifier mangling. The capability charges $0.002 per API request, while the browser execution path can use the same pure implementation. For production deployment, run the resulting program’s own tests as you would after any source-processing step. This tool protects lexical boundaries and delimiter balance, but tests remain the strongest confirmation for code that depends on unusual grammar contexts or host-specific behavior.