Formatting and minifying are the same operation pointed in opposite directions. One rewrites code so a person can read it; the other strips everything a person needed and leaves only what the machine requires. Neither changes what the code does.
That last point is what makes both safe, and it is worth stating plainly: a formatter and a minifier both parse your code into a syntax tree and print it back out. They are not editing text with clever find-and-replace.
Formatting is about ending the argument
The practical value of a formatter is not that its output is beautiful. It is that the output is deterministic — the same input always produces the same result, so nobody has to have an opinion about it.
A team that runs a formatter stops reviewing indentation and starts reviewing logic. Diffs stop containing whitespace churn. The style question is settled once, by a tool, rather than repeatedly, by people.
Because it reprints from the parsed structure rather than nudging text around, a formatter also doubles as a syntax check: code that will not parse will not format. That is why formatting JSON is the fastest way to find the trailing comma in a 4,000-line file — the formatter stops exactly where the structure breaks.
The same applies across languages: JavaScript and TypeScript, CSS, HTML and SQL all benefit, though SQL benefits most dramatically — a long query written as one line is nearly unreadable, and the same query with its clauses broken out is obvious.
Minifying is about bytes on the wire
A minifier removes what the browser does not need: whitespace, comments, and any structure that exists purely for human benefit. For JavaScript it goes further, renaming local variables to single letters and dropping code it can prove is unreachable.
Typical savings are substantial — often 30 to 60% before compression for JavaScript, less for CSS, which has less redundancy to remove. On a page loading several hundred kilobytes of script, that is the difference between a fast first render and a slow one.
Worth knowing: minification and gzip are not redundant. They compound. Minifying shortens the actual symbols; gzip then compresses the repeated patterns in what remains. Doing both beats doing either.
Minifying JavaScript and minifying CSS are the two that matter most, because they are what a browser must download and parse before the page becomes usable.
Why variable renaming is safe, and where it stops
Renaming userAccountBalance to a sounds dangerous and is not, because a minifier only renames names it can see the full scope of. A local variable inside a function is invisible from outside, so shortening it cannot break anything.
What it will not touch is anything reachable from elsewhere: exported names, object properties accessed as strings, and globals. This is also the failure mode to know about — code that looks up a property dynamically, like obj[someString], can break under aggressive settings, because the minifier cannot see the connection.
Source maps put the readable version back
Debugging minified code would be miserable, and you do not have to. A source map is a separate file recording which position in the minified output corresponds to which line of the original.
With one present, browser dev tools show you the original code while running the minified version. Breakpoints land on real lines, and stack traces name real functions. It costs nothing at runtime, because the map is only fetched when dev tools are open.
Which to use when
The rule is simply which audience the code is for.
Format everything you commit. Source control should hold readable code, and the formatter should run automatically so nobody has to remember.
Minify only what ships to a browser, and only as a build step. Minified code should never be what you edit or commit — it is output, and it is regenerated every build.
For anything else — a config file, a query you are debugging, an API response you are reading — formatting is the only one you want. Nothing is being downloaded, so the bytes do not matter and the readability does.