Markup that has lost its line breaks is technically identical to markup that has kept them, and completely different to work with. A div opened four hundred characters ago and closed six hundred characters later is invisible to a reader and obvious the moment the document is indented, which is why this is usually the first thing to do with a page you did not write.
Everything runs locally. The markup is scanned and reprinted by JavaScript in your own tab, so a page containing customer data, an internal admin screen or an unreleased design never leaves your device.
When an HTML formatter actually helps
The usual trigger is a saved or served page. Production HTML is minified, template output arrives on one line, and the browser view source panel shows you exactly what was sent rather than something readable. Running it through an html beautifier turns a wall of text into a structure you can scan.
The second trigger is a hunt for an unclosed element. When a layout breaks in a way that suggests a stray tag, indentation makes the fault obvious, because the indent level fails to return to where it should and every following element drifts to the right.
- You are reading a served page and need to find one component inside it.
- A layout bug suggests an element was opened and never closed.
- Template output arrived on a single line and needs review before a commit.
- You want to indent html code consistently across a set of static pages.
- A diff is unreadable because the two versions break lines differently.
How this HTML formatter decides where to break a line
The scanner splits the document into tags and the text between them, then walks that sequence keeping an indent counter. An opening tag prints at the current level and raises the counter. A closing tag lowers the counter and prints at the new level. Text between tags prints at the level of its parent.
Void elements such as img, br, input and meta never raise the counter, because they have no closing tag to match. Elements written with the self closing slash are treated the same way. The result is that an image inside a paragraph does not push everything after it one level too deep.
Comments and doctype declarations are emitted as their own lines. Conditional comments and template placeholders that look like tags are copied through rather than interpreted, so a document containing template syntax survives formatting intact.
Elements whose whitespace must not be touched
Inside a pre element, whitespace is content. Adding an indent in front of a line of preformatted text changes what the user sees, so pre is copied out verbatim along with everything nested inside it. The same rule applies to textarea, where leading whitespace becomes part of the field value.
Script and style elements are also copied through untouched. Their contents are JavaScript and CSS rather than markup, and reindenting them with an HTML aware scanner would produce nonsense. The HTML formatter leaves them for a language aware tool to handle.
Everywhere else, whitespace between elements collapses under the normal CSS white space rules, which is what makes reindentation safe in the first place. The one visible exception is a run of inline elements, where a line break between them renders as a single space. Because that space can matter, the formatter keeps short inline runs on one line rather than exploding every span onto its own.
Choosing an indent and handling attributes
Two spaces is the default when you pretty print html. Markup nests deeply, and four spaces on a component eight levels down pushes the content off the right of most editor windows before you have written any of it. Tabs remain available for teams that let each developer choose their own width.
Attributes are left on the same line as their tag regardless of how many there are. Breaking attributes onto separate lines is a legitimate style, but it interacts badly with long class lists and makes a diff noisier rather than clearer, so it is not done here.
Attribute values are never rewritten. Quoting style is preserved, ordering is preserved, and a value containing angle brackets inside quotes is recognised as part of the attribute rather than as the end of the tag.
Working with server rendered and templated markup
Output from a template engine is the most common thing people paste in after minified pages. Handlebars, Jinja, Blade and Liquid all use delimiters that are not HTML tags, so they are treated as text and printed where they sit. That is normally what you want when you format html online to review generated output.
Templates that open a block in one branch and close it in another are the exception. A construct that emits an opening div inside a conditional and its closing div somewhere else will leave the indent counter unbalanced, and the tool will say so rather than silently producing misleading output.
The HTML formatter is happy with a fragment rather than a whole document. No doctype or body element is required, and a bare list of list items indents as sensibly as a full page.
| Node | Treatment |
|---|---|
| Block element | Own line, raises the indent level |
| Void element | Own line, indent level unchanged |
| Inline run | Kept together on one line where short |
| pre and textarea | Copied out verbatim |
| script and style | Copied out verbatim |
| Comment | Own line, kept or dropped by option |
How to use the HTML formatter
- 1
Add your markup
Paste HTML into the input box or drop a .html file onto the drop area. The file is read on your own machine.
- 2
Pick an indent width
Choose two spaces, four spaces or a tab. Two spaces suits deeply nested markup best.
- 3
Choose how comments are handled
Keep comments to preserve build markers and author notes, or drop them for the shortest readable output.
- 4
Format and take the result
Press format, then copy the markup or download it as an .html file ready to open in an editor.
Related tools worth bookmarking
Sources and further reading
- WHATWG: HTML syntaxThe living standard section that defines tags, void elements and raw text elements such as script and style.html.spec.whatwg.org
- MDN: HTML element referencePer element documentation, including which elements are void and which preserve whitespace.developer.mozilla.org
- W3C: CSS Text Module Level 3The specification for white space processing, which is why reindenting markup is normally invisible.w3.org
Frequently asked questions
Common questions about the html formatter.
In almost every case no, because whitespace between block level elements collapses and has no visual effect. The exceptions are pre and textarea, whose contents are copied out untouched precisely so that their rendering cannot change.
They are copied through exactly as written. Their contents are JavaScript and CSS rather than markup, so an HTML aware scanner has no business reindenting them. Use a dedicated formatter for each language if you want those blocks readable too.
Yes. The scanner is tolerant rather than strict, so unmatched tags are printed where they appear rather than aborting the run. The tool reports that the nesting did not balance, which usually points straight at the missing closing tag.
Yes. Anything that is not an HTML tag is treated as text and printed in place, including template delimiters, so generated markup can be formatted for review. Block constructs split across branches may leave the indent unbalanced, which the tool reports.
No. The scan and the reprint both happen inside your browser tab using ordinary JavaScript. Open the network panel of your developer tools while formatting and you will see no request carrying the file.