Minify & Beautify
Every Minify & Beautify tool on Toolz.dev: 4 free utilities that run entirely in your browser. No signup, no uploads, no downloads.
Minifying removes what a machine does not need: whitespace, comments, and in some formats the last semicolon before a closing brace. Beautifying puts it back. The four tools here do both directions on the formats where it matters, so the same page handles making a file small for delivery and making it readable for debugging.
Use the CSS minifier and the HTML minifier on files you are shipping by hand, or in reverse on a stylesheet you need to read. Use the JSON minifier for payloads, and the SQL formatter mostly in the beautifying direction, since the reason to format a query is usually that a colleague has to review it.
What minifying removes from each format
| Format | Removed when minifying | Typical saving before compression |
|---|---|---|
| CSS | Whitespace, comments, trailing semicolons | 10-20% |
| HTML | Whitespace between blocks, comments | 5-15% |
| JSON | All insignificant whitespace | 10-30%, more when deeply nested |
| SQL | Line breaks and indentation | Rarely the point; readability is |
How much minifying is still worth after gzip
This is the honest question, because every server worth using compresses text responses with gzip or Brotli, and those algorithms are extremely good at repeated whitespace. A file that minifies to 70 percent of its size often compresses to nearly the same bytes either way, so the incremental saving from minifying before compression is real but modest, typically in the low tens of percent rather than the headline figure an uncompressed comparison shows.
Where it still earns its place: minified JSON is smaller in memory and marginally faster to parse, which matters for a large payload on a slow device. Minified CSS and HTML reduce the bytes the compressor has to work through and the parse work in the browser. And any file served without compression - a data URI, an inline block, a file on a misconfigured host - keeps the full saving. What minifying does not do is make your site fast on its own: images and blocking third-party scripts dominate almost every page weight problem.
Where whitespace is not insignificant
HTML is the format with a genuine hazard, because whitespace between inline elements is rendered. Collapsing the space between two spans joins two words; removing the newline between list items usually does not. This is why an aggressive HTML minifier can change a rendered page, and why the HTML minifier leaves the contents of pre and textarea alone, where every character is significant by definition.
CSS has a smaller version of the same problem: whitespace inside a selector is the descendant combinator, so removing it changes what the rule matches. JSON has none, since whitespace outside string literals is entirely insignificant, which is why a JSON minifier is the only completely safe one of the four. The general rule is that beautifying is always reversible in meaning and minifying is not, so keep the readable file as the source and treat the minified one as build output.
Formatting SQL is a different job
Nobody minifies SQL to save bandwidth. The SQL formatter exists because queries arrive as a single 400-character line out of a log, an ORM or a colleague, and a query you cannot read is a query you cannot review. Consistent indentation of the clauses, one condition per line and aligned joins turn a wall of text into something whose logic is visible, which is where a missing join condition or an unintended cartesian product becomes obvious.
The reverse direction has one real use: putting a formatted query back onto a single line so it fits a config value, a JSON field or a shell argument without embedded newlines. Everything on this page runs client-side, which is worth noting for SQL in particular, since a query pasted into a formatting service often contains table names, column names and sometimes literal values from production.
Frequently asked questions
- Is minifying still worth it when the server uses gzip?
- Yes, but the gain is smaller than uncompressed comparisons suggest. Compression already handles repeated whitespace well, so minifying first typically saves an additional 10 to 20 percent rather than the headline number. It matters most for large JSON payloads, for parse time, and for anything served without compression at all.
- Can minifying HTML break a page?
- It can, because whitespace between inline elements is rendered. Collapsing the space between two spans joins the words together, so an aggressive minifier can change how text reads. Content inside pre and textarea is significant by definition and is left untouched here. Minifying JSON, by contrast, is always safe.
- Does minified JSON parse faster?
- Slightly, and it uses less memory in transit. The parser has fewer bytes to scan, which is measurable on large payloads and irrelevant on small ones. The larger benefit for an API is bandwidth, particularly for deeply nested documents where indentation can be a third of the file.
- Is beautified output identical in meaning to the minified input?
- For CSS, JSON and SQL, yes: formatting changes only insignificant whitespace. For HTML it is equivalent as markup but not necessarily pixel-identical, since added whitespace between inline elements is rendered as a space. Treat the readable file as your source and the minified file as build output rather than round-tripping.
- Why format SQL rather than minify it?
- Because the problem SQL has is legibility, not size. A query arriving as one long line from a log or an ORM hides its structure, and formatting it into clauses is what makes a missing join condition or an accidental cross join visible. Minifying SQL is useful only for fitting a query into a config value or a single-line field.
- Is my code uploaded when I minify it?
- No. All four tools run client-side, in your browser. This is worth knowing for SQL and for JSON payloads especially, since queries and API responses pasted into an online formatter routinely contain schema details and real customer data.