HTML formatter and markup compactor

Whitespace in HTML is not decoration

Most HTML formatters share one assumption: that the spaces and line breaks between tags are yours to rearrange. For most of a document that is true. For several specific parts of it, it is completely false — and those parts are exactly the ones people notice when they break.

Inside <pre> and <textarea>, every space and every line break is rendered exactly as written. That is the entire purpose of those elements. A formatter that re-indents the document line by line will add its indentation inside them too, and a code sample that was flush left is suddenly two, four or six spaces in — on every nested level, compounding. The same applies to anything you have styled with white-space: pre, which this tool detects from an inline style attribute and leaves alone.

A complete stylesheet is a different grammar and job. Use the CSS minifier when you want parser-checked compact CSS; this HTML formatter deliberately preserves the contents of each <style> region instead of rewriting a second language.

<code> is a subtler case. Browsers do not treat it as whitespace-sensitive by default, so strictly speaking a formatter is allowed to reflow it. In practice almost every stylesheet on the web gives it a monospace font and many give it white-space: pre, and what is inside it is nearly always a snippet where the spacing is the content. This tool treats it as untouchable, and says so in the panel before it formats anything rather than after.

What HTML is

HTML

Full name	HyperText Markup Language
Extension	.html, .htm
Format type	Markup document
MIME type	text/html

If the source is strict XML rather than browser HTML, use the XML formatter. XML requires well-formed nesting, preserves namespace identity, and treats case and whitespace under different rules. Sending it through an HTML recovery parser would answer a different question even when the angle brackets look familiar.

Inline elements, and the space you cannot see

Here is the failure that is hardest to spot. These two lines do not render the same way:

<span>7</span><span>8</span> renders as 78. <span>7</span> <span>8</span> renders as 7 8. A single space between two inline elements is visible text. So is a newline, because any run of whitespace in normal flow collapses to exactly one space — not to nothing.

That is why a naive pretty-printer that puts every element on its own line is dangerous. Breaking after </span> introduces a space that was not in your document. Joining two lines removes one that was. Navigation menus, breadcrumb separators, icon-plus-label buttons and inline badges all shift by a few pixels, and the diff looks like pure formatting.

There is a practical consequence for reviewing your own work. Reformatting a document touches nearly every line, so a version control diff of a reformat is unreadable and the one real change hides inside it. The way around it is to reformat both versions at the same settings and then compare them with whitespace differences set aside but still listed — an ignore option that hides what it ignored would put you back where you started.

This formatter never breaks a line inside a run of inline content. Text, links, spans, emphasis, images, inputs and buttons stay on one line together with the spacing they arrived with. When it indents a run that already spanned several lines, it only changes whitespace that already contained a newline — which collapses to one space no matter how wide it is, so the rendered result is provably identical. Compact markup does not alter those text runs at all; it only removes redundant spacing inside tags.

Four things this HTML formatter refuses to do

It does not close void elements. <br>, <img>, <input>, <meta> and <hr> have no closing tag in HTML, and </br> is not a thing — browsers read it as a second line break. If your source wrote </br>, the tool reports it and keeps it so that line break is not lost. If it wrote <br />, that form is kept; the tool neither adds the slash nor strips it.

It does not change the case of tags or attributes. This looks like harmless tidying and it is not. SVG has viewBox, preserveAspectRatio and linearGradient, all case-sensitive. Angular has [ngIf]. Vue has :class and component names that only work capitalized. Lowercasing a document breaks all three.

It does not add closing tags you never wrote. In HTML, </li>, </p>, </td> and </tr> are optional. A list written without them is correct, and writing them in is a change to your file, not a formatting of it.

It does not rewrite template syntax. A <?php ?> block, or anything else that is not markup, is copied through byte for byte and flagged, because moving code the browser never sees is how a formatter silently breaks a build.

The same restraint applies to embedded data. A <script type="application/json"> block, a Next.js hydration payload, an analytics configuration object — these are not markup, so indenting them is somebody else's job. Lift the contents out and format the JSON on its own, where an unexpected token gets a line and a column rather than being swallowed by a parser that was looking for tags. If the block does not exist yet, the FAQ schema generator builds the narrower FAQPage shape from visible questions and safely wraps it for HTML.

Attribute values get the same hands-off treatment, and the one people notice is href. A tracking link arrives with its query string escaped — &utm_content=spring%20sale%2Bvip — and leaving it alone is not laziness but correctness, since unescaping it in place would change where the link points. When you need to read one of those rather than reformat it, decode the URL separately and leave the markup as it is.

Broken markup gets reported, not repaired

Browsers never reject HTML. They rebuild it: an unclosed <div> gets closed somewhere, a stray </section> is dropped, mis-nested <b> and <i> get reordered into something that parses. That is excellent for rendering a page and useless for finding the mistake, which is why this tool uses its own parser instead of the browser's.

HTML is error-tolerant by specification. The parsing rules define a recovery for nearly every mistake, which is why a page with an unclosed tag still renders and why nobody notices until something moves. That tolerance is exactly why a formatter has to speak up: if the markup you pasted is structurally different from what you meant, a tool that silently agrees with the browser hands you back a tidy version of the wrong tree. So the position is named — the line, the column, and the line itself with the trouble marked — together with what went wrong and what to do about it. The region involved is copied through exactly as you wrote it rather than restructured, and the receipt says so. Guessing which tag you meant to close is how a formatter turns a small typo into a moved paragraph.

Structural errors and runtime performance are also different investigations. Tidying source indentation does not make a rendered page faster. When the evidence comes from a PageSpeed or Lighthouse JSON export, the Lighthouse report analyzer preserves the recorded audit IDs and builds a version-aware action queue instead of treating formatted HTML as a speed fix.

Compacting markup without changing text

Compact markup removes redundant syntax spacing inside tags — for example, it turns <main id = "x"> into <main id="x">. It does not remove whitespace between elements or collapse text, because those bytes may render visibly or become significant under an external stylesheet. It leaves <pre>, <textarea>, <code>, <script> and <style> untouched, keeps attribute quoting as you wrote it, and keeps conditional comments even when you ask for comments to be removed — those are instructions to old browsers, not notes to yourself.

Markup that arrives from a generator rather than from a person is a common thing to run through here, because generated output tends to be one long line. The lorem ipsum generator is one such source: its HTML mode emits real <p> and <ul> structure rather than a string with tags in it, which is exactly the input this page can indent without having to guess where an element begins.

Inline SVG is still its own case-sensitive language inside that HTML. Once the graphic is separated into a standalone file, the SVG optimizer can remove representation-level bytes while checking its viewBox, IDs, accessibility relationships, and rendered pixels. An HTML minifier cannot make those vector-specific claims safely.

All of it happens on your own machine, with nothing here that could accept the markup even if the page tried to hand it over — and there is a reason that matters for HTML in particular: the markup people need to reformat is usually an email template, a checkout page, an internal admin view or an exported CMS block. Those carry customer names, order numbers, internal URLs and API keys in data- attributes far more often than anyone expects. Open your browser's Network tab and paste something in: the list stays exactly where it was.