HTML formatter, beautifier and viewer

What this tool does

This is an HTML formatter, beautifier and viewer in a single page. Paste markup of any size — a fragment out of a template, a minified page pulled from view-source, an email body, a block of markup an editor produced — press Format, and it is parsed and laid out as an indented, collapsible tree. Tag names, attribute names, attribute values, comments and text are coloured differently, every element reports how many children it holds, and each branch folds away so a long document can be read one level at a time.

There is a second thing happening that a plain formatter does not give you. The tree is built by your browser own parser, which means you are not looking at your text re-indented — you are looking at the document your browser actually constructs from that text. Where the two differ, the difference is the interesting part, and the chapter below on repaired markup explains why.

Each result appears above the one before it, so two versions of a fragment can be compared without losing the first. Results can be removed one at a time or cleared all at once, and nothing survives a refresh.

Formatter, beautifier, viewer — and the validator question

A formatter re-prints markup with consistent whitespace: one element per line, a fixed indent per level of nesting, a predictable place for every angle bracket. Beautify is the older word for the same operation, borrowed from the JavaScript tooling world; a beautifier and a formatter are the same tool under two names. Neither changes what the markup means, only where the line breaks fall — with one caveat about whitespace that has its own chapter below.

A viewer goes further. Rather than printing text it renders the parsed document as a structure you can operate: fold a table shut, count the children of a container, follow one branch of a deeply nested layout without tracking closing tags by eye.

A validator is the word that does not quite fit HTML, and it is worth being precise instead of claiming otherwise. HTML has no parse errors in the sense XML or JSON do: the specification requires a browser to accept whatever it is handed and construct a document anyway. So there is nothing here to fail on, and any tool that says your HTML is "valid" is really checking conformance to the specification — unknown attributes, elements in places the content model forbids, a missing required attribute — which is a different job, done by a conformance checker such as the W3C validator.

What this page gives you instead is arguably more useful day to day: it shows the document your browser built. If a tag was closed in the wrong order or left open, you will see where the browser decided it belonged, which is the behaviour your CSS and your JavaScript will actually meet.

Your markup never leaves your browser

Nothing you paste here becomes a network request. The text you paste is parsed by your own browser, rendered into the page and held in memory only — nothing is posted to a server, written to a cookie or saved in local storage. Refreshing clears every result, and closing the tab disposes of the data.

Markup looks less sensitive than a JSON payload, right up until you look at what tends to be inside it. A page copied out of a logged-in session carries hidden form fields, CSRF tokens, session identifiers in URLs, a customer name in a heading, an order history in a table, sometimes an entire invoice. An email body pasted in to work out why it renders badly is somebody correspondence. A formatter that uploads all of that has turned a five-second layout question into a data transfer.

Because the parsing happens in your browser, none of that arises. Open your network tab while you use the page: apart from the analytics beacon the site sends on every page load — a URL and a page title — formatting produces no request at all. Disconnect from the network entirely and the tool keeps working, which is the only demonstration of the claim that does not require taking anyone word for it.

One consequence worth naming: parsing markup means the browser may resolve references inside it. This page renders the document as an inert tree of text rather than displaying it as a page, so scripts do not execute — but if you paste markup containing an img tag, treat the source as untrusted the way you would anywhere else.

What the browser does to broken markup

The HTML parser is required to produce a document no matter what it is given, and the rules it follows to do that are surprisingly opinionated. Seeing them applied to your own markup explains a great many bugs that look like CSS problems.

Some of the common repairs: a tr pasted directly inside a table gains an implicit tbody around it, which is why a stylesheet selector written as table > tr matches nothing. A p element is closed automatically the moment a block element opens inside it, so a div written inside a paragraph ends up as its sibling rather than its child. Content that appears before the first element is moved into the body, and a fragment with no html element at all is given one, along with a head. Overlapping tags are unwound and re-nested. An unclosed element swallows everything after it until something forces it shut.

None of that is an error, and no tool will warn you about it — the document is simply different from the one you thought you wrote. The tree here shows the outcome, so a paragraph that mysteriously lost its styling, a table row that ignores a selector, or a container whose children ended up one level too high all become visible in a few seconds rather than after an hour with the inspector.

Beautify, minify and the whitespace caveat

Minified HTML exists for the same reason minified JSON does: whitespace between tags is bytes on the wire, and a build step removes it. What is left is a single line where the structure is carried entirely by punctuation, which is exactly the information a reader needs and the one thing a single line will not show. Beautifying converts that back into shape — nesting becomes depth on the page, and the outline of the document is legible before any content has been read.

HTML carries a caveat that JSON does not, and it is worth being blunt about it. In HTML, whitespace between inline elements is rendered. The space in <a>one</a> <a>two</a> is a real space on screen, and moving those two links onto separate indented lines preserves it, while joining them removes it. That is why a beautifier can, in specific cases, change how a page looks — inline-block layouts and white-space: pre blocks are the usual victims.

The practical rule: beautify to read and to debug, which is what this page is for, and let your build pipeline decide the whitespace of what you actually ship. If you copy the beautified output back into a template, check any inline sequence and any preformatted block before assuming the two are equivalent.

A worked example

Take a minified order card: a section with a data attribute, a heading, a paragraph containing a line break, a table with two rows written without a tbody, a comment and an image. It is one line of about three hundred and fifty characters, and nothing about its structure is visible.

Formatted, the header counts the elements, the section reports its children, and the table shows a tbody that was never typed — the browser inserted it, and that single line explains why a selector written against the table directly would fail. The br and the img appear without closing tags because they are void elements, the comment is greyed out, and folding the table away leaves the card structure in four lines. Press "Load a sample" to see exactly that document rendered.