JavaScript Minifier & Beautifier
Minify JavaScript to cut file size, or beautify it to read it clearly. Strings, regex literals and template literals are left untouched.
100% free. Runs entirely in your browser - your files and data never leave your device and nothing is uploaded to any server.
edit_noteInput
outputOutput
About this tool
Minify JavaScript (shortening variable names, removing whitespace and comments, to produce the smallest possible file for production) or beautifies it (restoring readable formatting from a minified/compressed file) - the JS equivalent of the CSS minifier/beautifier.
How to use this tool
- Paste JavaScript codeInsert raw or minified JS source into the editor.
- Choose minify or beautifyCompress for production or expand for inspection/debugging.
- Process and review outputVerify syntax and quickly scan transformed result.
- Export to workflowCopy output into your bundle pipeline or investigation notes.
What JavaScript minification does
A minifier removes whitespace and comments, shortens local variable and function names, and rewrites some expressions into shorter equivalents. The code behaves exactly the same, but the file can be half the size or smaller, which speeds up page loads.
Beautifying a minified file restores the layout but not the original names. Keep source maps in your build if you need to debug minified production code.
Key features
- Shrinks JS files to improve download and parse performance.
- Makes compressed scripts readable during debugging and audits.
- Useful for quick transformations without a local build setup.
- Supports both optimization and reverse-formatting in one tool.
Common uses
- Preparing deployment-ready JavaScript assets.
- Reading minified vendor scripts during bug investigation.
- Sharing cleaner code snippets in documentation.
- Comparing code behavior before/after minification.
Tips for better results
- Test runtime behavior after minification in the same browser targets you support.
- Keep original source and source maps for maintainable debugging.
- Beautify first when auditing unknown compressed code.
- Use linting before minification to catch syntax issues early.
Mistakes to avoid
- Assuming beautify can restore original variable names after minification.
- Minifying code with unresolved syntax errors.
- Deploying transformed code without smoke-testing core flows.
- Treating minified output as the canonical file to edit.
Frequently asked questions
Standard minification preserves the exact behavior of your code - it only compresses naming and whitespace. Code that relies on unusual, non-standard tricks around variable names or whitespace-sensitive parsing quirks (rare in practice) could theoretically behave differently, but this is uncommon for typical code.
Beautifying restores indentation and line breaks, making minified code far more readable - though original variable/function names are usually already shortened during minification and won't be restored to their original meaningful names.
Smaller files download and parse faster, which directly improves page load performance - especially important at scale across many visitors and slower network connections.
A source map links minified code back to the original lines, so browser errors and the debugger show readable code. Generate one in your build tool for production debugging; keep it off public servers if the source is private.
Minifiers rename local variables to single letters, and the original names are not stored in the file. Beautifying restores the layout, not the names - only a source map can bring those back.
Typically 30-60% before compression, depending on how many comments and long names the code has. Combined with gzip or Brotli on the server, the transferred size often drops much further.