HTML
Minifier
Remove comments, collapse whitespace, and reduce your HTML file size. Fast, free, and entirely in your browser.
How It Works
Paste HTML
Paste or type your HTML code into the input area.
Minify
Click Minify to remove comments and collapse whitespace.
Copy or Download
Copy the minified code or download it as an .html file.
Minify HTML online to reduce page weight, save bandwidth, and improve Core Web Vitals scores. ConverterUp's HTML minifier removes comments and collapses whitespace — including the gaps between tags — while leaving your markup and attributes untouched. Front-end developers and static-site builders can paste their template, click minify, see the savings, and copy or download the smaller file. Minification runs in your browser, so proprietary markup, internal templates, and unreleased landing pages stay completely private.
What gets removed during minification
Whitespace is the biggest win. Hand-written HTML and template-engine output contain hundreds of newlines, tabs, and runs of spaces that the browser never renders. The minifier collapses every whitespace sequence to a single space and removes the whitespace between tags, typically shaving 15–25 % off raw size before gzip.
Comments () are stripped, including conditional comments for old Internet Explorer and server-side include directives — if your templates rely on those, keep them out of the minifier.
Optional tags per the HTML5 spec — the closing ,
, , , and several others — can be omitted because the parser infers them. ConverterUp does not remove them: it only strips comments and whitespace, which keeps the output safe to open in any editor.Heavier optimizations — dropping redundant attributes like type='text/javascript', removing quotes around attribute values, collapsing boolean attributes — are left to build tools such as html-minifier-terser. ConverterUp keeps attributes exactly as written.
When NOT to minify HTML
Never minify the file you commit to source control. Minified HTML is unreadable, undiffable, and impossible to review in a PR. Keep the source template human-readable and minify only the build artifact that goes to the CDN. The same rule applies to email templates, MJML output, and JSX/template engine output.
Skip minification during local development. Source maps for HTML do not exist (unlike JS/CSS), so a broken minified template is much harder to debug than a broken source template. Most dev servers (Vite, Next.js, Astro) serve unminified HTML in development and minify only in production builds.
Avoid minifying inside template engines that depend on whitespace semantics. Liquid, Handlebars, EJS, and Jinja generally tolerate whitespace removal, but Pug/Jade and Slim are whitespace-sensitive by design — minifying their output post-render is fine; minifying the template itself is destructive. Same for Markdown and MDX sources.
Be careful with
,
Build pipeline integration: where this fits
For one-off minification (a single template, an HTML email, a static landing page generated by a no-code tool), paste-into-ConverterUp is the fastest path. For ongoing production sites, minification belongs in the build step. Doing it manually after each deploy is error-prone and skips the source-map benefits.
Next.js, Astro, and Gatsby minify HTML automatically in production builds via html-minifier-terser. SvelteKit and Nuxt do the same. If you use these frameworks, the static output is already minified — paste-minifying again gains nothing. Webpack users add html-webpack-plugin with minify: true. 11ty users add an HTML transform that pipes the output through a minifier.
Server-rendered apps (Rails, Django, Laravel, Express + EJS) usually do not minify by default. The win from minifying server-rendered HTML is real (10–25 % on first-byte size) but small once gzip/brotli kicks in. Most teams skip it because the build complexity outweighs the byte savings on TLS+brotli connections.
Don't compare apples to oranges: a minified HTML file is smaller on disk, but the network savings after gzip/brotli are often only 2–5 % because compressors already deduplicate runs of whitespace. Minify to improve parse time in the browser more than to save bandwidth — the browser still has to read every byte.
Frequently asked questions
How much can HTML usually be minified?
Typical reductions are 15-30 % for hand-written HTML and up to 50 % for documents with heavy whitespace and HTML comments. Combine with gzip or brotli compression for additional savings on the wire.
Does minification break inline JavaScript or CSS?
Inline scripts and styles are not rewritten, but their whitespace is collapsed like the rest of the document. Code that relies on line breaks — JavaScript without semicolons, or // single-line comments — can break, so minify pages with inline scripts in your build pipeline instead.
Are HTML comments removed?
Yes, all of them — including conditional comments for old Internet Explorer. If a comment must survive (a license notice or a template directive), add it back after minifying.
What is the maximum HTML size?
There is no fixed limit; documents of a few megabytes minify in well under a second. For production sites, make minification part of your build pipeline.
Does minifying HTML hurt SEO or accessibility?
No, when done correctly. Search engines parse the DOM after the browser parses HTML, so whitespace and comments are invisible to them. Accessibility is unaffected because <code>aria-*</code> attributes, <code>alt</code> text, semantic tags, and the rendered text are all preserved. Only the bytes change.
Can I minify Handlebars, EJS, or other templated HTML?
Often yes, because template tags such as {{ }}, <%= %> and {% %} are left as they are — only comments and whitespace change. Check the output of whitespace-sensitive templates (Pug, Slim) and prefer minifying the rendered HTML rather than the source template.