HTML Minifier
Remove comments and unnecessary whitespace from HTML.
Remove comments and unnecessary whitespace from HTML.
The HTML Minifier removes HTML comments and collapses unnecessary whitespace between tags to reduce file size. It is useful for preparing production markup without manually stripping formatting.
Removing unnecessary whitespace, line breaks and comments from HTML reduces file size and can modestly improve page load speed, particularly on larger pages or when combined with minifying accompanying CSS and JavaScript files.
For related tasks, try Markdown to HTML Converter, HTML Entity Encoder / Decoder or JSON Formatter & Validator.
The tool removes text matching HTML comment syntax, then collapses runs of whitespace between tags into a single space and trims the result.
Multi-line, indented HTML with comments is reduced to a single compact block with comments removed and extra whitespace collapsed.
A block of HTML with generous indentation and blank lines between elements can often shrink by 10-20% in file size purely from whitespace and comment removal, without changing anything about how the page actually looks or behaves.
Minifying HTML makes the source code much harder for a human to read, so always keep an unminified, well-formatted original version of your HTML in your source files or version control, and only serve the minified version to actual visitors' browsers.
Minification strips comments and unnecessary whitespace from HTML so the file is smaller. The page looks the same to visitors, but fewer bytes are sent. Typical savings are about 10 to 20 percent for hand-written HTML with generous indentation. Smaller files load a little faster, especially on slow mobile connections, though image, script and CSS sizes usually matter more.
Not all whitespace is safe to remove. Spaces between inline elements, such as two spans or links, can be visible, and removing them can join words together. Text inside pre and textarea elements keeps its spacing. Inline scripts that rely on comments, and conditional comments for old Internet Explorer, may break if comments are removed. Check the result in the browser after minifying and keep the original source.
Most servers also compress text with gzip or Brotli, which already removes much of the repeated whitespace, so minification adds a smaller extra gain. It is still worthwhile for production pages. For a website you maintain regularly, automate minification in your build process instead of doing it by hand, so the source stays readable and the published file stays small. This tool is handy for quick tests and one-off snippets.
After you minify, validate the page and test it on a phone and a desktop. Look at forms, tables, navigation and any content with preserved line breaks. Compare the file size before and after to confirm the saving. Keep a copy of the unminified file, since minified code is hard to edit. Do not paste confidential pages into online tools if they contain private information; this tool runs in your browser.
Measure the result before you decide how much effort to invest. A page of 120 KB might shrink to 100 KB after minifying, and after gzip compression the transferred size might be about 20 KB against 17 KB, a small difference. Images, fonts and scripts usually account for most of a page's weight, so optimising them often saves much more. Minify as one step in a wider performance routine, and measure the page with a speed testing tool to see whether the change is noticeable.
Consider a small menu written with indentation and a comment: an unordered list that contains a comment line saying menu, then a list item with a link to the home page, each on its own line with spaces. After minifying, the comment and the line breaks are gone and the markup runs together on one line, about half as many characters. The browser displays exactly the same page. On a real page with hundreds of lines of indented markup and comments, the saving adds up, especially for sites that serve millions of page views.
HTML is often only a small part of a page's weight. Images usually dominate, followed by scripts, fonts and stylesheets. Converting images to modern formats such as WebP or AVIF, resizing them to the display size, and loading below-the-fold images lazily often saves far more than minifying HTML. Compressing text with gzip or Brotli, caching files in the browser and using a content delivery network help too. Treat HTML minification as a finishing touch after you have dealt with the larger items.
A few constructs are sensitive. Whitespace between inline elements affects how they are spaced, so removing it can join neighbouring words or buttons. Text inside pre and textarea tags must keep its spaces and line breaks. Inline scripts that depend on specific formatting, conditional comments for old browsers and template markers used by your content management system can also be damaged. After minifying, load the page, check layouts at different widths, submit a form and test any interactive features before you publish.
Keep your readable source files under version control and produce the minified version as part of a build or deploy step, so that you never edit minified code by hand. Run the page through a speed-testing tool before and after, and look at the whole result, not only the HTML size. For a small static site, a manual pass with this tool is fine. For a site that changes often, use an automated tool in your build process. Whatever the approach, test the published page, since a successful build does not guarantee that the page looks right.
Minification removes characters that a browser does not need, such as comments and extra whitespace, without changing how the page works. Compression such as gzip or Brotli reduces file size during transfer. A build step is an automated process that prepares files for release. Render-blocking resources delay the display of a page. A content delivery network serves files from locations near the visitor. Lazy loading delays images until needed. Page weight is the total size of everything that a page loads.
Minifying HTML typically saves 10 to 20 percent of its size, and compression saves much more on top. Images often make up half or more of a page's weight, so optimise them first. Keep the original file, and test layouts, forms and scripts after minifying. Whitespace inside pre and textarea elements must stay. Use a speed-testing tool before and after to see whether the change makes a measurable difference.
Minifying removes comments and extra whitespace that browsers do not need, so the file becomes smaller while the page looks the same. Before you publish the result, check three things. First, whitespace inside pre and textarea elements is meaningful, so it must stay. Second, a space between two inline elements can matter, for example between two links. Third, comments that carry instructions, such as conditional comments for old browsers, should be reviewed. Keep the readable original in your project and publish the minified copy only. After uploading, open the page in a browser, test the main features and compare the size, because compression on the server often reduces the benefit.
No, only the HTML structure and whitespace are affected.
Whitespace-sensitive elements such as <pre> can be affected by aggressive whitespace collapsing, so review the result for such content.
No, minifying removes formatting; keep your original formatted file separately.
No, minification only removes whitespace, line breaks and comments that don't affect rendering; the visual appearance and functionality of the page remain identical to a properly minified original.
For a one-off file, a tool like this is convenient; for an ongoing website project, most developers automate minification as part of their build process.