JS Formatter

About JavaScript formatting

Minifying JavaScript strips comments, whitespace, and shortens names where it's safe to, producing smaller files for production. Beautifying does the opposite — it re-indents and expands code so it's readable again.

This minifies with Terser, the same engine used inside most modern JavaScript build pipelines, so the output matches what a production bundler would produce. Minifying and beautifying only ever change whitespace, comments, and — where provably safe — identifier names; they never transpile syntax for older browsers or add polyfills, so code that uses a feature your target browsers lack will still need that handled separately. Neither direction produces a source map, so treat the beautified output as a reading copy, not a drop-in replacement for the original source during debugging.

Where you'll run into it

• Shrinking a script before deploying it to production
• Un-minifying a vendor bundle to read or debug it
• Cleaning up code pasted from a minified source
• Standardizing formatting before pasting code into documentation

Frequently asked

Will minifying break my code?
Minifying preserves behavior — only whitespace, comments, and, where safe, identifiers change. Code that depends on exact source formatting, which is rare, could be affected.

Does this obfuscate my code?
No. Minifying shrinks size; obfuscation deliberately makes code hard to read. This tool only does the former.

Is my code sent anywhere else?
No. It's processed on the server for that one request only and isn't stored or logged.

Does this generate a source map?
No. A source map lets a browser's debugger show the original, unminified source while running the minified file, but that requires keeping the mapping alongside the deployed code — out of scope for a one-off paste-and-convert tool like this one. If you need source maps in production, generate them as part of your normal build step, where the mapping file can be hosted or uploaded alongside the bundle.