HTML Formatter

This page reindents markup. It doesn't validate it, minify it or rewrite your tags. It takes the document, hands it to the browser and prints the tree it gets back with consistent indentation.

Why it parses instead of pattern-matching

The input goes through DOMParser, the same HTML parser the browser uses for a real page, and the output comes from walking the node tree it produces. Most of how this page behaves follows from that choice. A parser knows the difference between a < that opens a tag and a < sitting inside a string, and a regular expression doesn't.

A regex-based formatter breaks in the same few ways every time:

• <script>if (a < b && c > d)</script> was split at the comparison operators, which were read as tag boundaries. The script came out shredded.
• Any attribute containing an angle bracket (<div data-tpl="<%= name %>">, or an inline SVG path with a > in its data) broke the element around it.
• Whitespace inside <pre> was reindented, which changes what the browser actually renders.

What is preserved byte for byte

The contents of <pre>, <textarea>, <script> and <style> are emitted exactly as they arrived, with no reindenting or trimming. In the first two, whitespace is content, and the page looks different if you change it. The other two hold a different language entirely, and reindenting that isn't this tool's job.

Comments are kept. Attribute values are re-serialised with their contents intact. Inline elements such as <a>, <span>, <strong> and <code> stay on the line with the text around them. If you broke read the <a href="#">docs</a> first across three lines, the extra whitespace would show up in the rendered output as gaps.

Void elements are recognised, so <br>, <img>, <meta> and their siblings never get a spurious closing tag or an extra indent level.

The one setting

Indent is 2 spaces, 4 spaces or a tab, and that's the whole configuration. It's deliberate: a formatter with thirty options is a formatter whose output you can't predict.

What it will not tell you

The browser's parser is forgiving by specification, so it silently repairs a great deal. An unclosed <div> gets closed for you. A <p> inside a <p> gets split. A <td> outside a table gets relocated. You get a valid tree as a result, but it may not be the tree you wrote, and the differences are the interesting part. If the output has moved elements around, you've found a real bug in your markup and not in the formatter. Run the source through the W3C validator to see it named properly.

This page doesn't shrink anything either. Formatting adds bytes on purpose. Minification for production belongs in a build step, and for the assets around the markup there's CSS Minifier and JS Minifier.

A note on very large documents

Parsing and reserialising a whole 2 MB page works, but the tree walk and the syntax-highlighted view both grow linearly with the size of the document, and you'll feel it. It's built for formatting a component or a template fragment.

The markup you paste is parsed inside your own tab and never sent anywhere. The draft is kept in sessionStorage and disappears with the tab, or straight away if you use the "Clear it now" link.