Skip to the tool
DevToolBench

HTML Formatter

Indent or minify HTML without changing how it renders.

0 chars
Elements
0
Comments found
0
Lines
0
Characters
0

Everything runs in your browser. Nothing you type is sent to a server.

Found a bug in this tool? Report it.

Share this tool

What the HTML formatter does

This HTML formatter takes markup that arrived as one long line — from a CMS export, a template engine or the output of a build step — and indents it so the structure is readable, with each block element on its own line and nested elements one level further in. It also works the other way as an HTML minifier online, flattening a document to a single line without changing how it renders. It all runs in your browser, so pasting a page that holds internal links or customer data sends it nowhere.

It is a hand-written tokeniser rather than the browser's parser. That matters because DOMParser repairs the document before you can see it: it moves elements, adds a <tbody> and normalises attributes, and a formatter built on it shows you a different document from the one you pasted.

How to use it

  1. Paste the HTML into the input — a full page or a fragment both work.
  2. Choose Beautify for indented output or Minify for one line, then pick 2 spaces, 4 spaces or tabs.
  3. Decide whether comments stay or go, then copy the result or download it as an .html file.

Whitespace rules the browser follows

HTML collapses whitespace: a run of spaces and line breaks inside text renders as a single space. Between two block elements it renders as nothing. That is what makes it possible to pretty print HTML at all, and it is also the trap. A line break between <strong> and the next word is a visible space, so a formatter that puts every tag on its own line changes the text on the page.

So this html beautifier draws the line where the browser does. Block elements — div, p, section, ul, li, table and the rest — get their own lines. Text and inline elements such as a, span, em, code, img and input stay together on one line, with runs of whitespace reduced to one space. An element whose content is all inline, like a paragraph or a link, is written on a single line.

Void elements and optional end tags

Void elements such as <br>, <img>, <input> and <meta> have no content and no closing tag, and they are written the way you wrote them: <br> stays <br>, and <br/> becomes <br />. A stray </br> is ignored, as browsers ignore it.

Several elements have optional closing tags — li, p, td, tr, dt, dd and option among them — and a lot of hand-written HTML leaves them out. The formatter knows when the next element implicitly closes the previous one, as the HTML parsing rules define it, and writes the closing tag out. Missing closing tags on anything else are reported with a line and column.

What is never touched

<pre> and <textarea> keep their whitespace because it is what the reader sees. <script> and <style> are not HTML at all, and reindenting their contents with HTML rules would break a template literal or a CSS string. All four are copied from the opening tag to the closing tag without a single change.

If the markup is XML rather than HTML — a sitemap, an RSS feed, an SVG — use the XML formatter, which applies XML's stricter rules. To produce HTML from Markdown in the first place, the Markdown to HTML converter does that, and its output can be pasted straight back here.

Frequently asked questions

Can formatting HTML change how the page looks?

It can if the formatter is careless, because a line break between two inline elements renders as a space. This one only adds or removes whitespace next to block elements such as div, p and li, where the browser discards it anyway. Text and inline elements like a, strong and span are kept together on one line, so the words on the page stay the same.

Why did it add closing tags I never wrote?

HTML lets you leave out the closing tag of elements such as li, p, td, tr and option, and the browser closes them for you when the next one starts. The formatter works out the same boundaries and writes them down, so </li> appears where the browser already assumed it. The rendered page is the same; the source just says so explicitly.

What happens inside pre, textarea, script and style?

Nothing. Whitespace inside pre and textarea is content the reader sees, and the inside of script and style is JavaScript and CSS rather than HTML. Each of those elements is copied through byte for byte, from its opening tag to its closing tag, in both beautify and minify mode.

Why does it report an error instead of fixing my markup?

When a closing tag does not match, only you know which one is wrong. A browser silently repairs the tree in a way that often moves content, and a formatter that did the same would hide the bug. You get the line, the column and both tag names, and closing tags that HTML genuinely allows you to omit are accepted without complaint.

Does the HTML minifier remove comments?

Only if you ask it to. Comments are kept by default, because some of them matter — licence headers, build markers, template placeholders. Set Comments to Remove and they are dropped in both modes.

Related tools

Updated