Skip to content
ToolBoxGeniehome

HTML Formatter

Developer Tools · Added

Beautify and indent HTML markup, or strip it down for production. It reads your markup with a tokeniser rather than a pattern match, so a > inside an attribute, a < inside a script and a comment containing tags all survive intact.

Mode

Processed in your browser. Nothing you paste is uploaded.

How to use the html formatter

  1. 1Paste your HTML. A fragment is fine — it does not have to be a whole document.
  2. 2Choose Beautify to indent it, or Minify to compress it for delivery.
  3. 3For beautifying, pick two spaces, four spaces or tabs.
  4. 4For minifying, decide whether comments should go. Conditional comments are kept either way, because they are markup rather than annotation.
  5. 5Copy the result or download it as a file.

Examples

Indenting a minified document

Input
<div><p>Hello</p></div>
Result
Each element on its own line, nested two spaces per level

Inline elements are the exception — a run like "Hello <b>world</b>" stays on one line, because breaking it would insert whitespace the browser renders.

Minifying for production

Input
A formatted 12 KB page with comments and indentation
Result
Around 9 KB with the layout collapsed

Whitespace between two block-level tags is dropped; whitespace between inline elements is collapsed to a single space rather than removed, because deleting it would join the words either side.

A script that would break a regex formatter

Input
<script>if (a < b) { x() }</script>
Result
The script body is returned byte for byte

The < inside the condition is not markup. Script and style contents are captured whole and never reflowed, and the same applies to pre and textarea.

About the html formatter

Why HTML is harder to format than it looks

A formatter that finds tags with a regular expression works on the examples people test it with and fails on real pages. The failures are specific and predictable: a greater-than sign inside an attribute value looks exactly like the end of a tag, a less-than sign inside a script looks exactly like the start of one, and a comment containing markup looks like markup. Each of those produces output that is subtly wrong rather than obviously broken, which is the worst kind of wrong.

This tool reads the markup as a stream of tokens instead. Attribute values are scanned with quote tracking so their contents cannot be mistaken for structure. Script and style contents are captured whole up to the matching close tag and never examined as markup. Comments and doctypes are recognised before tags are. None of that is clever; it is just the amount of care the format actually requires.

Where whitespace matters, and where it does not

HTML collapses runs of whitespace when it renders, which leads to the assumption that whitespace can be added and removed freely. It cannot. A single space between two inline elements is rendered as a space, so removing it joins the words together, and adding one where there was none pushes them apart. The difference between correct and broken output here is one character.

The rules this formatter follows come directly from that. Between two block-level tags, whitespace is not rendered and is removed when minifying. Around inline elements it collapses to exactly one space and is never deleted. Inside pre and textarea it is rendered literally and is copied through byte for byte. Beautifying keeps inline runs on a single line for the same reason: the indentation you would gain is not worth the space you would introduce.

Frequently asked questions

Can reformatting HTML change how my page looks?
Yes, and any tool claiming otherwise is overselling. Whitespace between inline elements is rendered, so moving a <span> onto its own line can add a space that was not there. This formatter is built to avoid the common cases: runs of inline elements stay on one line, and pre, textarea, script and style contents pass through untouched. That covers almost everything in practice, but the risk is inherent to HTML rather than to the implementation, so check the result on anything layout-sensitive.
Does it fix broken markup?
No, deliberately. Unclosed tags are reported underneath the output, but nothing is inserted, removed or reordered to repair them. A formatter that quietly rewrites your markup is much harder to trust than one that shows you the problem and leaves the decision to you.
Why did minifying save less than I expected?
Because whitespace is usually a small share of a page. Most of an HTML document is tags, attributes and text, none of which minifying touches. Savings of ten to twenty per cent are typical, and the real wins on page weight are almost always in images, fonts and JavaScript rather than markup. Enabling gzip or Brotli on your server does more for HTML than minifying does.
Is my markup uploaded?
No. Your markup is parsed by the same browser that would render it, in the tab you already have open. That is worth knowing because of what people routinely paste into a formatter without thinking about it: an unreleased template, a transactional email with a real customer's name and order in it, the HTML of an internal admin screen. All of those leave the building the moment a tool posts them to a server, and none of them do here.
What happens to conditional comments?
They are kept even when comment removal is on. A conditional comment such as <!--[if IE]> is markup that old Internet Explorer acts on, not a note to a developer, so stripping it would change what a browser does rather than just shrinking the file.

Related tools