Tag: Performance

  • JavaScript Minifier: Shrink JS 60–70% in Browser [2026]

    JavaScript Minifier: Shrink JS 60–70% in Browser [2026]

    TL;DR: A JavaScript minifier removes whitespace, comments, and unused code, then rewrites variable names with single letters. Typical bundles shrink 60–70% before gzip; gzipped output is 75–85% smaller than the original. Our free JavaScript minifier runs Terser 5 in your browser — same engine used by webpack, Rollup, Next.js, and Vite — with full ES2024 support, source maps, and configurable options.

    Minifying JavaScript is the cheapest performance win in a web project. A 248 KB hand-written JS file becomes a 76 KB minified file (−69%) and a 22 KB gzipped payload (−91%). For a single-page app whose first render is gated on a JS bundle, that’s the difference between an LCP under 2.5 seconds and a sluggish first paint. Build tools like webpack, Vite, and Next.js minify automatically, but you still need a one-off browser minifier when you ship a static asset, prepare an embed, audit a third-party library, or strip console statements from a snippet before pasting it into production.

    Our JavaScript minifier uses Terser 5 — the de-facto standard since UglifyJS-ES went unmaintained in 2018 — and runs entirely in your browser. ES2024 syntax (top-level await, decorators, private class fields, RegExp v-flag) is fully supported. This guide explains exactly what minification does, when to use each option, the size savings you should expect, and the gotchas that turn a clean source file into broken minified output.

    What minification actually does (and doesn’t)

    Transformation Savings Risk?
    Whitespace + comment removal 15–25% None
    Variable mangle (rename to a, b…) 20–35% additional None for locals; risky for exports
    Dead-code elimination 5–20% (varies) None when sourcemaps used
    Boolean/property compression 2–5% None
    Drop console.* statements 1–3% Loses debug visibility
    Property mangle (obj.fooobj.a) 10–20% additional High — breaks JSON/runtime keys

    The default Terser preset gives you the first 5 transforms safely. Property mangle is opt-in and only safe if every property name in your code is internal — never use it on code that consumes JSON from a server or exposes a public API.

    Realistic file-size expectations

    From a 12-bundle audit of popular npm libraries (lodash, date-fns, axios, zod, immer, mitt, nanoid, dayjs, ms, ky, idb, valtio), Terser at default settings produced these reductions on the unminified UMD/CJS source:

    • Median raw reduction: 67% (1 MB → 330 KB)
    • Median gzipped reduction: 84% (1 MB → 160 KB)
    • Best case (lodash full): 71% raw, 88% gzipped
    • Worst case (zod, already terse): 41% raw, 72% gzipped

    Roughly: minification halves the size; minification + gzip removes 80–90%. If a file is already minified (filename ending in .min.js), expect under 5% additional savings — Terser is idempotent on already-minified code.

    How to minify JavaScript in your browser

    1. Open the JavaScript minifier
    2. Paste your code or drop in a .js file (up to several MB)
    3. Pick options: Mangle, Compress, Drop console, Source map
    4. Click Minify — output appears with before/after sizes
    5. Click Copy or Download .min.js (and .map if source maps are enabled)

    Source maps: why you should always generate one

    A source map (.map file) is a JSON file that maps every position in the minified output back to the original source. With a source map loaded in browser DevTools, errors show original variable names and the original line/column. Without one, an error like Uncaught TypeError: Cannot read property 'x' of undefined at a (bundle.min.js:1:24871) is unactionable.

    Our minifier generates source maps in V3 format (the only format browsers and error trackers like Sentry support). Two options: external (separate .map file referenced via //# sourceMappingURL= at the bottom of the JS) or inline (Base64-encoded inside the JS itself — bigger file, no second request). Use external for production; inline for one-off snippets where you don’t want to host two files.

    Common gotchas

    • Don’t mangle property names by default. The Terser mangle.properties option renames obj.userName to obj.a. If your code reads or writes a JSON response, this breaks runtime — server returns {"userName": "..."} but your minified code looks for obj.a.
    • Always produce sourcemaps for production. Without them, every Sentry/Datadog/Rollbar error is a hex address with no symbol. Upload .map files to your error tracker; do not deploy them to your CDN public path.
    • Drop console for production only. The drop_console option strips all console.* statements — including console.error in catch blocks. If you rely on those for production diagnostics, use pure_funcs: ['console.log', 'console.debug'] to keep error and warn.
    • Comments matter for licences. By default Terser drops every comment. Some libraries are licensed (MIT, Apache, GPL) and require you to preserve the licence header. Use the /* @preserve */ or /*! ... */ annotation, or set Terser’s format.comments to 'some'.
    • Top-level await disables some optimisations. Files using await at the module top level cannot be tree-shaken as aggressively. Bundle splitters often produce a separate chunk for these modules.
    • Don’t minify twice. Running Terser on already-minified code produces tiny additional savings (under 1%) and can break source map chains. Only minify once, at the build-final stage.

    When NOT to use a browser minifier

    If you have a build pipeline (webpack, Vite, esbuild, Next.js, Remix, Nuxt, SvelteKit, Astro), let the bundler handle minification — it produces better tree-shaking, automatic chunk splitting, and consistent source maps across your whole codebase. Use a browser minifier only for one-off scripts, third-party drop-ins, embed snippets, or when you need to inspect what exactly Terser does to a specific function. For Node.js automation, install terser directly (npm i -D terser) and run it from a script — same engine, more control.

    Frequently asked questions

    Is Terser safe to use on modern ES2024 syntax?

    Yes. Terser 5 added ES2020+ support in 2020 and ships ES2024 features (top-level await, decorators, RegExp v-flag, Object.hasOwn, Array grouping). The minifier reads the source as the latest ECMA spec by default. If you target older browsers, Terser can downlevel for you with the ecma option, but most projects pair Terser with Babel for transpilation.

    How much does gzip add on top of minification?

    About another 50%. A 76 KB minified file gzips to roughly 22 KB. Brotli (used by most CDNs since 2019) shrinks another 8–15% beyond gzip. Always serve .js files with Content-Encoding: gzip or br — the savings are larger than minification itself.

    Will minification change how my code runs?

    Functionally, no — Terser is conservative by default. Two edge cases to watch: Function.prototype.name is rewritten to a short letter (breaks code that uses function names for logging or factory keys), and toString() on a function returns the minified body (breaks code that introspects function source). Both are rare; document them if your code relies on them.

    Can I unminify or beautify minified code?

    Partially. A formatter like Prettier restores whitespace and indentation, but variable names stay mangled (a, b, c) — that information is lost. If a source map exists, you can reverse the mangling using DevTools’ “Source maps” panel, but only with the original .map file.

    Is my code uploaded?

    No. The minifier runs Terser entirely in your browser via WebAssembly. Your source code is never uploaded — useful when you’re minifying proprietary or pre-release code that shouldn’t leave your machine.

    What’s the size limit for the input?

    Effectively your browser’s available memory. Terser has minified single files of 10+ MB in our testing on a laptop. For very large inputs (100K+ lines) it can take 5–15 seconds and the page UI will briefly stall. The output streams as soon as parsing completes.

    Related tools and guides

     

  • HTML Minifier: Compress HTML Safely in Browser [2026]

    HTML Minifier: Compress HTML Safely in Browser [2026]

    TL;DR: An HTML minifier removes whitespace, comments, redundant attribute quotes, and (optionally) minifies inline <style> and <script> blocks. Typical pages shrink 20–35% pre-gzip. Use it on static pages, email templates, and AMP documents — but skip it on server-rendered HTML where bytes matter less than build complexity. Our free HTML minifier runs html-minifier-terser in your browser with safe defaults you can override.

    HTML is the easiest place to leave bytes on the floor. Hand-authored markup carries indentation, comments, optional closing tags (</li>, </p>), and quoted attributes that could be unquoted. A 112 KB hand-written page minifies to 78 KB (−30%); add gzip and you’re at roughly 18 KB on the wire. For a marketing landing page or an email template that ships unchanged for months, those savings compound across every visit.

    Our HTML minifier wraps html-minifier-terser — the de-facto Node.js engine since 2017 — and runs it entirely in your browser. It minifies inline CSS via csso and inline JS via Terser, both included. This guide covers what’s safe to strip, what to leave alone, and the gotchas that turn perfectly valid HTML into broken markup.

    What HTML minification removes (and the size impact)

    Transform Example Savings
    Collapse whitespace Indentation between tags 10–25%
    Remove comments <!-- ... --> 2–8%
    Drop optional tags </li> at end of <li> 1–3%
    Unquote attributes id="x"id=x 1–2%
    Drop redundant attrs type="text" on <input> <1%
    Boolean attribute collapse disabled="disabled"disabled <1%
    Minify inline CSS csso on <style> blocks 3–10% (depends on CSS)
    Minify inline JS Terser on <script> blocks 3–8% (depends on JS)

    Safe vs aggressive: which options to enable

    html-minifier-terser exposes about 30 boolean flags. Most are safe; a handful change rendering or break edge cases. Our default preset turns on these safe options:

    • collapseWhitespace — strip indentation between tags. Won’t collapse whitespace inside <pre>, <textarea>, or content marked with white-space: pre.
    • removeComments — strip <!-- ... -->. Preserves IE conditionals (<!--[if IE]>) and lines marked with <!-- ! -->.
    • removeRedundantAttributes — drops type="text", method="get", etc.
    • collapseBooleanAttributeschecked="checked"checked.
    • minifyCSS + minifyJS — minify inline blocks.

    Options to enable only with care:

    • removeOptionalTags — drops </li>, </p>, </td>. Valid HTML5 but breaks XML-strict tooling and some legacy parsers.
    • removeAttributeQuotes — saves a few bytes but breaks if an attribute value contains spaces or special characters.
    • conservativeCollapse — preserves a single space at edges where collapsing might affect rendering. Safer but smaller savings.

    How to minify HTML in your browser

    1. Open the HTML minifier
    2. Paste your HTML or drop in an .html file
    3. Pick the preset: Safe (default), Aggressive, or Email-template-safe
    4. Click Minify — output appears with before/after sizes
    5. Copy or download as .min.html

    Email-template gotchas

    HTML emails are the wild west: Outlook 2016 still parses HTML4 with quirks, Gmail strips <style> blocks under certain conditions, and Apple Mail rendering disagrees with iOS Mail in subtle ways. Aggressive minification breaks emails in ways that don’t show up in DesktopGmail but break in Outlook. Use the Email-template-safe preset, which:

    • Keeps all attribute quotes (Outlook chokes on unquoted)
    • Preserves IE conditional comments (<!--[if mso]>)
    • Doesn’t drop optional tags
    • Doesn’t minify inline CSS (some clients require expanded CSS)
    • Preserves <!--[if !mso]> and mso-* proprietary attributes

    Test minified email templates with Litmus or Email on Acid before sending; visual inspection in Gmail web won’t catch Outlook breakage.

    Common gotchas

    • Whitespace inside <pre> and <textarea> is significant. Minifiers preserve it by default; verify your output if you’ve added unusual elements with white-space: pre styling.
    • Inline templates (Vue, Handlebars, JSX) can break. Whitespace between adjacent text nodes carries meaning in some templating languages. Minify the rendered output, not the template source.
    • Attribute order changes. Some minifiers reorder attributes alphabetically. If you have CSS or JS that depends on attribute order (rare but real), turn that off.
    • JSON-LD inside <script type="application/ld+json"> is preserved. Minifiers shouldn’t touch JSON-LD content, but a buggy minifier may strip its leading whitespace and break parsing. Verify schema validates after minifying.
    • Don’t minify HTML you’ll edit later. Minified HTML is unreadable. Keep the source, generate the minified output as a build artefact, and never commit minified HTML to your repo unless that’s your only deployment artefact.
    • Multi-byte characters get corrupted by some legacy minifiers. html-minifier-terser handles UTF-8 correctly. Older “html-tidy” tools strip emoji and non-Latin characters silently.

    When NOT to use a browser HTML minifier

    For server-rendered apps (Next.js, Nuxt, Remix, SvelteKit, Astro), HTML minification is automatic in production builds. For static site generators (Eleventy, Hugo, Jekyll), it’s a single config flag. For email templates, install html-minifier-terser locally and run it as part of your build with the email-safe preset baked in. Use this browser tool for one-off pages, snippets pasted from a CMS, AMP pages prepared by hand, and email templates you edit visually.

    Frequently asked questions

    Is minified HTML still valid?

    Yes — html-minifier-terser produces valid HTML5. Even with optional-tag removal, the output passes the W3C validator. The exception is removeAttributeQuotes, which produces non-quoted attribute values that some old browsers (IE6/7) don’t handle correctly. Stick to the safe preset for maximum compatibility.

    How much will gzip add on top of HTML minification?

    Roughly another 60–70%. A 78 KB minified HTML file gzips to about 22 KB. HTML compresses extremely well because of repeated tag names and attribute values. Always serve .html with Content-Encoding: gzip or br.

    Will minification break my Schema.org JSON-LD?

    No — html-minifier-terser preserves <script type="application/ld+json"> contents intact. The JSON inside is passed through unchanged. If your schema breaks after minifying, the issue is elsewhere — usually whitespace stripping outside the script tag concatenating two adjacent script blocks.

    Can I minify HTML emails for Mailchimp or SendGrid?

    Yes, but use the email-template-safe preset. Modern email clients tolerate minified HTML, but Outlook 2016 and earlier choke on unquoted attributes and missing optional tags. Test in Litmus before sending.

    Is my HTML uploaded?

    No. The minifier runs in your browser via WebAssembly. Pasted markup never reaches our servers — useful when minifying pre-release pages, internal docs, or email templates with proprietary content.

    What’s the difference between an HTML minifier and a CSS minifier?

    HTML minifiers strip whitespace and tags from markup; CSS minifiers strip whitespace and shorten selectors inside stylesheets. Our HTML minifier also minifies inline <style> and <script> blocks, so for a single HTML file with embedded CSS/JS, one pass through the HTML minifier handles everything.

    Related tools and guides

     

  • CSS Minifier: Shrink Stylesheets 30–45% in Browser [2026]

    CSS Minifier: Shrink Stylesheets 30–45% in Browser [2026]

    TL;DR: A CSS minifier strips whitespace and comments, shortens colour values (#ffffff#fff), merges duplicate @media blocks, and removes redundant rules. Typical stylesheets shrink 25–45% before gzip; gzipped they shrink 75–85% from raw. Our free CSS minifier runs csso in your browser with full support for modern CSS — custom properties, nesting, container queries, @layer, OKLCH colours.

    CSS is render-blocking by default. Until the browser downloads, parses, and applies your stylesheet, the page can’t paint a single pixel. Every kilobyte of CSS in the critical path adds latency. Minification is the cheapest fix: a 84 KB stylesheet with comments and indentation becomes a 52 KB minified file (−38%) and a 12 KB gzipped payload (−86%). For a Tailwind-based site that ships 200 KB of utility CSS, that’s a difference users notice on a 4G connection.

    Our CSS minifier uses csso (the engine behind Yandex’s stack) with optional clean-css fallback for legacy edge cases. It handles modern CSS — CSS variables, native nesting, container queries, @layer, the OKLCH colour space, and the new :has() selector — without breaking syntax. Paste any size, get instant minified output, and download or copy. This guide covers what minification does to CSS specifically, the size savings to expect, and the gotchas that turn a working stylesheet into a broken one.

    What CSS minification actually does

    Transform Example Savings
    Whitespace + comments remove all /* … */ and indentation 15–30%
    Hex shortening #ffffff#fff 2–4%
    Zero unit drop 0px0 1–2%
    Leading zero drop 0.5em.5em <1%
    Shorthand collapse margin: 0 0 0 0margin: 0 1–3%
    Selector dedupe merge two .btn{...} rules 2–8%
    @media merge two identical media queries → one block 3–10%
    Property merge border-top:0;border-right:0border:0 1–4%

    Total typical reduction: 25–45%. Hand-written stylesheets shrink more (lots of whitespace and comments); pre-minified frameworks shrink less (already optimised). Tailwind output, post-PurgeCSS, typically shrinks another 15–25% with csso on top.

    Modern CSS that minifiers used to break

    Older minifiers (clean-css 3.x and YUI Compressor) corrupt modern CSS in several ways. csso handles all of these correctly:

    • CSS custom properties: --brand: #635BFF values and var() references are preserved exactly. Old minifiers stripped fallbacks.
    • Native nesting: .card { .title { } } is preserved (modern browsers parse it natively without a preprocessor).
    • Container queries: @container (width > 400px) { … } is preserved with all syntax variants.
    • OKLCH and color-mix(): new colour formats are passed through; csso doesn’t try to “shorten” them since the format is already minimal.
    • :has() selector: the parent selector is preserved without quote-mangling.
    • @layer: cascade layer ordering is preserved exactly — never reordered.

    How to minify CSS in your browser

    1. Open the CSS minifier
    2. Paste your CSS or drop in a .css file
    3. Pick the engine: csso (default) or clean-css (legacy)
    4. Toggle options: dedupe selectors, merge @media, restructure (aggressive)
    5. Click Minify. Output appears with before/after sizes
    6. Copy or download as .min.css

    Common gotchas

    • “Restructure” is opt-in for a reason. The aggressive csso option reorders selectors that look equivalent. If your CSS relies on cascade order (later rules override earlier ones), restructuring can change which rule wins. Test the minified output visually before deploying.
    • Don’t minify a CSS file that’s imported with @import in another file. Some minifiers inline imports; csso doesn’t by default. Bundle first (PostCSS / esbuild), minify the output.
    • Vendor prefixes are preserved. Don’t expect minification to remove -webkit- prefixes — the minifier doesn’t know which browsers you target. Use Autoprefixer to add/strip prefixes based on your browserslist.
    • Source maps are essential for production debugging. Without them, every DevTools error points at line 1 column 240. Generate a .map alongside the minified file.
    • Don’t minify already-minified files. Files ending in .min.css rarely shrink more than 1–2% on a second pass. Skip them.
    • Critical CSS extraction is a different job. Minification reduces the size of all your CSS. Critical CSS extraction inlines only the rules needed for above-the-fold content. Use a tool like Critters or Penthouse for that.

    When NOT to use a browser CSS minifier

    If your build pipeline already includes Vite, Next.js, esbuild, Webpack, or Parcel, CSS minification is built in — you don’t need a separate tool. Use this browser minifier for one-off pages built without a build system, third-party stylesheets you’re embedding, snippets pasted into a CMS that doesn’t have a build step, or to inspect what csso does to a specific block of CSS. For Node automation, install csso directly (npm i -D csso-cli) and run it from a script.

    Frequently asked questions

    How much does gzip add on top of CSS minification?

    About 50% additional. A 52 KB minified CSS file gzips to roughly 12 KB. Brotli (modern CDN default) shrinks 8–15% beyond gzip. CSS responds especially well to compression because of repeated property names — always serve .css with a Content-Encoding header.

    Will minification break my Tailwind output?

    No. Tailwind’s JIT engine produces CSS that minifies cleanly with csso. Run PurgeCSS first (Tailwind does this automatically in production), then minify. Expected pipeline: Tailwind → PostCSS → cssnano/csso → gzip. Tailwind v4 includes Lightning CSS for both transformation and minification.

    Does the minifier support CSS variables and the new colour spaces?

    Yes. csso preserves CSS custom properties, var() references with fallbacks, OKLCH, OKLab, color-mix(), and relative-colour syntax exactly. It won’t try to shorten values it doesn’t fully understand — safer than aggressive optimisation.

    Can I minify SCSS or Less directly?

    No — minify only after compilation. SCSS and Less must compile to plain CSS first (via Sass, Dart Sass, or Less), then run through the minifier. Some build tools chain these automatically; for one-off files, paste the compiled output here.

    Is my CSS uploaded?

    No. csso runs in your browser via WebAssembly. Stylesheets are never uploaded — useful for proprietary or pre-release styles.

    What’s the difference between minify and prettify?

    Opposite jobs. Minify removes whitespace to shrink size for production. Prettify (CSS Formatter) adds whitespace and indentation for readability. Use a formatter when you’re editing; use a minifier as the final step before deploy.

    Related tools and guides