HTML, CSS & JavaScript Minifier — beautify and minify online

Each language gets a small, character-by-character state machine rather than a global regex pass. This matters because the three things that trip up naive minifiers — a `//` inside an HTML attribute or a CSS url(), a `:` inside a CSS string, a `/` that opens a JavaScript regex literal — all need surrounding context to be read correctly.

The HTML pass follows the same tag-vs-text tokenization the WHATWG parser uses. Standard <!-- ... --> comments are stripped; conditional comments (<!--[if IE]>…) and bang-prefixed comments are kept. Runs of whitespace inside text nodes collapse to a single space; whitespace flanking a tag boundary is dropped entirely. Anything inside <pre>, <textarea>, <script>, <style>, <code>, <svg>, or <math> is copied through byte-for-byte — those bodies are governed by another grammar.

The CSS pass follows CSS Syntax Module Level 3. The tokenizer recognises strings (single- and double-quoted) so a colon or comma inside one is never touched. Comments are stripped, except /*! … */ bangs — the convention every minifier respects for licence banners. Whitespace runs collapse, and the space adjacent to { } ; , : > ~ + is dropped. The last ; before a closing } goes too — it is optional by the spec.

The JavaScript passis Douglas Crockford's JSMin algorithm, lifted into TypeScript and extended to recognise ES2024 syntax: template literals (with ${expr} brace tracking), regex literals (disambiguated from division by inspecting the previous token), and Unicode identifiers. Whitespace is removed except where deleting it would either join two identifier characters (e.g. return foo must keep its space) or change semantics under automatic semicolon insertion. A bare return followed by a newline is preserved because ASI would otherwise insert a semicolon — collapsing the newline to a space changes what the function returns. Identifiers are never renamed and dead code is not removed, so stack traces and source maps remain meaningful.

Every successful run is cross-checked with an idempotency test: the engine minifies its own minified output and confirms it produces the same bytes. If the two ever differ, the page surfaces a warning under the output panel — a regression in the engine cannot ship unnoticed.

Two practical limits are worth stating. First, minification and server compression stack rather than compete: gzip and Brotli already collapse repeated whitespace, so minified-then-compressed is smaller than compressed alone — but the marginal saving on top of Brotli is usually only a few percent, and the readability and transfer wins are the real reason to minify. Second, the in-browser pass caps input at 5 MB; past that the tab would stall, so very large bundles belong in a build-time minifier instead. Neither limit changes the byte-for-byte guarantee on the files this tool does process.

Reach for minify when a file is going into production and every kilobyte over the wire counts — an inline <style> block in an HTML email, a hand-written landing page with no build step, or a snippet you are about to paste into a CMS field. Reach for beautifywhen you have inherited a minified file — a vendor script, a stylesheet copied from View Source — and need to read or debug it. The same engine runs both directions, so you can flip a minified blob back into indented source and back again without losing a byte of meaning.

Minifying is rarely the only step in a workflow, so the site keeps the neighbouring jobs one click away. The JSON formatter pretty-prints and validates the API payloads your script consumes; the regex tester lets you check a pattern before you paste it into code the minifier will then compress; and the Base64 encoder / decoder and URL encoder / decoder handle the encoding steps that usually sit right next to a minify task — data-URI images inlined into CSS, query strings built up in JavaScript. All of them run in the browser with no upload, exactly like this one.

• HTML Living Standard (WHATWG) — tokenization & parsing
• CSS Syntax Module Level 3 — tokenizer specification
• ECMAScript 2024 — lexical grammar and automatic semicolon insertion
• JSMin (Douglas Crockford, 2001) — the canonical safe-JS minifier

Implementation cross-checked against these specifications on 2026-07-19. The transforms run from pure state machines — there are no external library dependencies, so the algorithms above are the definitive description of what the engine does.