formaterTools Logo Formater Tools

JavaScript Minifier & Beautifier

Minify JavaScript to reduce file size or beautify for readability. Instant formatting and compression.

Upload a JavaScript file (max 5MB)

Beautify Options

How to Use:

  1. Paste your JavaScript code in the left textarea or upload a JS file
  2. Click "Beautify" to format code for readability or "Minify" to compress it
  3. Customize beautify options (indent size, spaces vs tabs)
  4. Copy the output or download it as a file

Benefits:

  • Minification: Reduces file size by removing unnecessary characters
  • Beautification: Makes code more readable with proper indentation
  • File Size Reduction: See size reduction statistics

What This Minifier Does (and Doesn't) Do to Your Code

This is a whitespace-and-comment minifier, not a full parser-based one like Terser or UglifyJS. Minify strips /* block */ and // line comments, collapses runs of whitespace to single spaces, and removes the space around { } ( ) ; , :. It does not rename or shorten your variable names, doesn't remove dead code, doesn't merge declarations, and doesn't tree-shake unused functions โ€” the kind of deeper size reduction a bundler's real minifier performs. Realistic size savings here come mostly from stripped comments and formatting whitespace, so expect a modest reduction on code that's already reasonably dense, and a bigger one on heavily-commented or generously-indented source.

A Gotcha Worth Testing Before You Ship Minified Output

The single-line comment stripper is a simple regex, /\/\/.*/g, applied without tracking whether it's inside a string. That matters because a URL literal like const url = "http://example.com"; contains a // sequence โ€” and this minifier will treat everything from that // to the end of the line as a comment and delete it, corrupting the string and likely breaking your code. Beautify is safer here: it tracks string and comment state character-by-character, so it correctly leaves // inside quotes alone. If your code contains URLs, protocol-relative paths, or any string with a double slash, always check the minified output before deploying it โ€” this is exactly the kind of naive-regex edge case that's easy to miss until it silently breaks a fetch call in production.

Where This Tool Fits (and Where It Doesn't)

Good fit: a small standalone script with no build step

A single hand-written utility script for a static site with no bundler in the pipeline โ€” stripping comments and whitespace here before uploading is faster than setting up Terser for one file.

Good fit: reading someone else's minified code

Paste a compressed third-party script into Beautify to see it broken into readable lines with real indentation, useful for understanding what a library or snippet actually does before you rely on it.

Poor fit: production bundles for a serious web app

Since there's no variable-name shortening or dead-code elimination, this won't get you the aggressive size reduction a real build-time minifier provides. For anything beyond a small script, a proper bundler step (esbuild, Terser, SWC) will do meaningfully better.

Poor fit: code containing URLs or regex literals with slashes

Because the comment stripper isn't string-aware, always spot-check minified output that contains string literals with // in them, or regex literals using forward slashes โ€” both are places this simple approach can misfire.

Frequently Asked Questions

My minified code broke โ€” a string got cut off mid-line. What happened?

This almost always means your code had a // sequence inside a string (commonly a URL like http://...). The comment-removal step doesn't distinguish a real comment from // inside quotes, so it deletes the rest of that line. Rewrite the URL to avoid the literal double-slash pattern being on its own, or minify with a proper parser-based tool for code containing such strings.

Why didn't my variable names get shortened like other minifiers do?

This tool only strips comments and collapses whitespace โ€” it doesn't rename identifiers. For the more aggressive size reduction that comes from shortening variable and function names, you'd need a full parser-based minifier such as Terser, which understands scope and can safely rename local variables.

Is it safe to minify code with regular expression literals?

Generally yes for whitespace collapsing, but be cautious: a regex like /\/\// or one containing what looks like a comment-start sequence could confuse the naive comment-stripping logic. Always diff or test minified output for code with unusual regex patterns.

Does Beautify recover the original variable names after minifying?

Only if they were never removed in the first place โ€” this minifier doesn't rename variables, so re-beautifying its own output keeps whatever names you started with. If you're beautifying code minified elsewhere (by a real minifier that shortened names), the short names are permanent; beautify only restores formatting, not identifiers.

What's a realistic size reduction to expect from Minify here?

It depends heavily on how much of your file was comments and indentation whitespace to begin with. Sparse, already-compact code might shrink only slightly; a heavily-commented file with generous spacing can shrink substantially more โ€” the live stats panel shows the exact percentage for your specific input.