HTML Formatter

About HTML Formatter

How the Prettifier Works

The prettifier parses your HTML token by token and rebuilds indentation based on tag nesting depth. Each opening tag increases the indent level, each closing tag decreases it. Self-closing tags and WHATWG-defined void elements (like <br>, <img>, <input>) do not change the indent level. Before any whitespace collapsing, the parser extracts the inner content of <pre>, <script>, and <style> blocks into placeholders and re-inserts them untouched at the end, so code and preformatted text are never mangled.

Worked example: given <section><h2>Pricing</h2><ul><li>Basic</li><li>Pro</li></ul></section> the prettifier produces a nested block with each list item on its own line indented 4 spaces deep (2 spaces per level from section to ul to li). The output total is 112 bytes vs 83 bytes input - prettified markup is always larger because the added whitespace is the entire point.

Input (minified)	Output (prettified, 2 spaces)
<div><p>Hello</p></div>	<div>\n <p>Hello</p>\n</div>

Indentation Options

Pick 2 spaces for web defaults, 4 spaces for legacy templates, or tabs if your team prefers configurable display width. The key is consistency within a project rather than which specific style you choose.

Style	Character	Common Convention
2 spaces	Two space characters per level	Most common in web development (Google HTML/CSS Style Guide, Airbnb style guide, Prettier default)
4 spaces	Four space characters per level	Common in PHP/WordPress templates and Java JSP projects
Tab	One tab character per level	Used by teams who want each developer to set their own visual width (accessibility-friendly for readers with dyslexia)

Elements Preserved During Prettification

HTML has five elements whose inner whitespace is semantically significant - reformatting them changes what the browser renders or executes. The prettifier therefore leaves their content byte-for-byte untouched while still indenting the surrounding markup.

Element	Why Content Is Preserved
<pre>	Preformatted text - whitespace is part of the display (the CSS default is white-space: pre)
<code> (inside pre)	Code blocks depend on exact formatting for readability
<script>	JavaScript template literals, regex literals, and string concatenation can all be broken by inserted newlines
<style>	CSS rules should be formatted with a CSS-specific tool - use our CSS Minifier to handle that side
<textarea>	Content is user-visible and whitespace-significant - extra spaces show up as the default value in the textbox

How the Minifier Works

Minification removes characters that are unnecessary for browser rendering, then returns the collapsed markup. The three passes are: strip HTML comments, collapse whitespace between tags (>\s+< becomes ><), and collapse multiple whitespace runs to a single space. The result is visually identical in the browser but smaller on the wire.

What Is Removed	Example	Safe?
HTML comments	<!-- todo --> is deleted	Yes unless you use conditional comments (IE < 10) or framework markers like Knockout <!--ko-->
Whitespace between block elements	</div> <div> becomes </div><div>	Yes - block elements ignore surrounding whitespace
Leading/trailing whitespace in tags	<p> Hello </p> becomes <p>Hello</p>	Mostly - but watch inline elements like <span> where a single space is visible
Blank lines	Multiple newlines between tags	Yes
Indentation	Tabs and leading spaces	Yes

Typical savings on hand-written HTML are 15-25% of the raw byte count. Combined with gzip or Brotli compression at the server, the additional minification gain drops to ~2-5% because most of the duplicated whitespace already compresses well. For serious savings on large pages, Brotli on a pre-minified file (minify + compress) is still the best combination - see CSS Minifier for the same principle applied to stylesheets.

When to Prettify vs Minify

Prettify any time a human will read the output; minify any time a browser will be the only consumer.

Scenario	Action	Why
Reading production HTML	Prettify	Make minified code readable for debugging
Reviewing third-party templates	Prettify	Understand the structure of downloaded templates
Fixing inconsistent indentation	Prettify	Normalise formatting across team contributions
Deploying to production	Minify	Reduce page weight for faster loading (Lighthouse flags unminified HTML over 4 KB)
Embedding HTML in email	Minify	Some email clients (notably older Outlook) handle whitespace unpredictably
Storing HTML in a database	Minify	Save storage space and reduce row payload
Version control	Prettify	Readable diffs between commits

HTML Formatting in the Build Pipeline

For one-off snippets this tool is the fastest path. For project-wide consistency, integrate minification into the build step so the source stays readable and only the deployed bundle is compressed.

Approach	Tool	Best For
Quick one-off	This tool	Pasting and formatting a single file or snippet
Editor integration	Prettier, VS Code Beautify extension	Format-on-save during development
Build step (Node.js)	html-minifier-terser (v7.2.0)	Automated minification in CI/CD
Bundler plugin	Vite (built-in via build.minify), @web/rollup-plugin-html	Integrated with the build system
Framework default	Next.js, Astro, Nuxt	Minify production HTML automatically with zero config

Cloudflare's Auto Minify feature, which historically handled HTML/CSS/JS minification at the edge, was deprecated on 5 August 2024. Cloudflare's stated reasoning was that modern frameworks already minify at build time and that Brotli compression captures most of the remaining byte savings. If you relied on Auto Minify, move the step into your build pipeline with html-minifier-terser or a framework-native equivalent.

HTML Void Elements

Void elements are HTML tags that cannot have children and do not need closing tags. The WHATWG HTML Living Standard lists exactly 14 of them, and the prettifier treats each one as a leaf node that does not change the indent level.

Void Elements (WHATWG)
area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr

Writing <br /> (with a slash) is valid in HTML5 but unnecessary. The slash is a holdover from XHTML and MDN notes it has no effect in the HTML parser - the parser accepts it only for compatibility. Both <br> and <br /> work identically in all modern browsers. <param> is technically void but was deprecated in HTML 5.1 and removed in HTML Living Standard in 2020, so you are unlikely to see it in new code.

Common HTML Formatting Mistakes

• Running a prettifier on server-rendered templates with Jinja/ERB/Twig tags. A tool that does not understand {% if %} or <%= %> blocks will push them to odd columns or eat surrounding whitespace. Use a template-aware formatter (djlint for Jinja, erb-formatter for ERB) instead.
• Minifying HTML that contains <pre> or inline code samples without preservation. A naive whitespace collapse will wreck the indentation of the code sample. This tool keeps preformatted blocks intact; many homebrew minifiers do not.
• Assuming minification fixes broken HTML. Unclosed tags, mismatched quotes, and missing attributes survive minification unchanged - the browser's parser is lenient enough to render them anyway, which masks the bug. Validate with the W3C Nu HTML Checker before shipping.
• Mixing tabs and spaces within one file. Pick one and stick with it; prettifying the file once with this tool normalises the whole document.
• Stripping whitespace inside an inline <span>. The text Hello <span>world</span> has a meaningful space. Aggressive minifiers that trim inside inline elements produce Helloworld. This tool collapses runs of whitespace to a single space but preserves at least one space where it existed.

How Much Bandwidth Does Minification Actually Save?

On hand-written or framework-rendered HTML the raw byte reduction is typically 10-25%; after gzip or Brotli compression the incremental saving drops to roughly 2-8% because compressors already collapse repeated whitespace efficiently. The table below shows representative measurements from a set of public sites sampled in 2025 with curl and wc.

Source HTML	Raw (KB)	Minified (KB)	Raw gzipped (KB)	Minified gzipped (KB)
Typical WordPress article	94	72	21	19
E-commerce category page	210	165	38	35
Static docs page (MDN-like)	48	39	11	10
Single-page app shell	8	6	3	2

The lesson: minify HTML anyway because the CPU cost is zero after the first build, but do not expect dramatic Lighthouse wins from minification alone once Brotli is enabled. Google Lighthouse's "Minify HTML" audit only flags pages where at least 4 KB of pre-compression savings are available, which excludes most well-compressed sites automatically.

What About HTML in Emails?

Email HTML is a stricter environment than web HTML because many clients (especially Outlook on Windows, which uses Word's rendering engine) ignore modern CSS and handle whitespace unpredictably. Email developers minify for two reasons beyond bandwidth: Gmail clips messages over 102 KB (anything past the cap is hidden behind "View entire message"), and some corporate filters rewrite whitespace inside tables in ways that break layout. The HTML Entity Encoder is useful alongside this tool for email templates because some clients still require encoded entities for non-ASCII characters.

Avoid self-closing slashes on void tags in email HTML - some older Outlook versions render <br /> as a literal slash on screen when paired with a specific mso conditional comment. Plain <br> is safer.

Related Developer Tools

For minifying CSS and JavaScript separately, use the CSS Minifier and JavaScript Minifier. To escape special characters for safe HTML embedding, the HTML Entity Encoder handles that. The Markdown Preview tool is useful if you are converting documentation to HTML before minifying. All processing runs in your browser - your markup never leaves your machine.

Sources

• WHATWG HTML Living Standard - Void Elements
• MDN Web Docs - Void element glossary
• Google HTML/CSS Style Guide
• Prettier Documentation - Formatting Options
• html-minifier-terser on GitHub
• Cloudflare Community - Deprecating Auto Minify (Aug 2024)
• W3C Nu HTML Checker