I build tools for a living, and the single most common thing I do before reading anyone's front end is run their HTML through a formatter. Server templates spit markup out on one line. Bundlers collapse it. A snippet someone pastes into Slack arrives with three levels of nesting flattened into a wall of angle brackets. I cannot debug what I cannot read, so the first move is always the same: paste it in, hit beautify, and let the structure reveal itself. This guide is the one I wish I had handed my younger self, who used to reindent markup by hand and got it wrong half the time.
TL;DR: An HTML formatter re-indents markup so you can read its structure, and minifies it back down so it ships small. Use beautify while you are building and debugging, minify for production. The HTML Formatter on toolz.dev does both in your browser, keeps your script, style, and pre content byte-for-byte, and never uploads a thing.
What is an HTML formatter?
An HTML formatter is a tool that parses your markup into its tag tree and prints it back with consistent indentation, one level per nesting depth. That is the beautify direction. The reverse, minify, strips the insignificant whitespace between tags so the file is as small as possible without changing how a browser renders it. Most good formatters, including the one on toolz.dev, do both from the same input.
The word "insignificant" is doing real work in that sentence. In HTML, some whitespace matters and some does not. The newline and two spaces you put between a closing </li> and the next <li> change nothing about the rendered page, so a formatter is free to add, remove, or normalize them. But the spaces inside a <pre> block, or the single space between two inline <a> elements, are part of what the user sees. A formatter that does not understand that difference will happily break your layout. This is the line between a formatter that helps and one you learn to distrust.
If you have used Prettier in your editor, you already know the feeling: you stop caring about indentation because a tool guarantees it. A browser-based formatter gives you the same guarantee for one-off snippets, generated output, and markup you do not control, without setting up a project.
Why does HTML end up messy in the first place?
It helps to know where the mess comes from, because it tells you what a formatter has to survive.
The first source is server rendering. A PHP template, a Rails view, or a Blade file emits HTML with whatever whitespace the template engine felt like producing, and after minification middleware runs, it is often a single line thousands of characters long. When something looks wrong in the browser and you hit "View Source," that is what you get.
The second source is copy and paste. You grab a component out of a design system, a fragment from a CMS, or an email template someone sent you, and it carries whatever spacing the source used: mixed tabs and spaces, inconsistent nesting, trailing whitespace. I spend a lot of my week inside WordPress and headless CMS output, and CMS-generated markup is some of the worst, because it is assembled from fragments that were each formatted differently.
The third source is generated markup. Build tools, WYSIWYG editors, and export functions produce HTML that was never meant to be read by a human. It is correct, but it is opaque. A formatter turns it back into something you can audit.
The common thread is that none of these sources cares whether you can read the result. That is your job, and a formatter is the fastest way to do it.
How do I format HTML online?
The workflow on toolz.dev takes about ten seconds:
- Open the HTML Formatter and paste your markup into the input panel. It does not matter if it is minified onto one line, indented inconsistently, or a bare fragment.
- Choose Beautify to expand it or Minify to compress it.
- For beautify, pick your indentation: 2 spaces, 4 spaces, or tabs. Two spaces is the common web default.
- Optionally tick "Remove comments" to strip HTML comments from the output.
- Copy the result or download it as an
.htmlfile.
Everything runs client side. The parser is JavaScript in your browser, so the markup never touches a server. That matters more than people assume, which I will come back to.
What is the difference between beautifying and minifying?
These are opposite operations that share a parser, and knowing when to reach for each is most of the skill.
Beautifying is for humans. It adds line breaks and indentation so the nesting is visible, which is what you want while editing, debugging, diffing two versions, or reviewing a pull request. When I am hunting a layout bug, I beautify first so I can see which element is unclosed or nested one level too deep.
Minifying is for machines. It removes the whitespace a browser ignores so the file is smaller and faster to transfer. You minify HTML for the same reason you minify CSS or JavaScript: bytes over the wire cost time, and on a large page the whitespace adds up. If you already lean on the HTML Minifier for production compression, the formatter is the tool you use to read that output again when something breaks.
Here is how the two directions compare on the decisions that actually differ:
| Aspect | Beautify | Minify |
|---|---|---|
| Goal | Readability | Smallest file |
| Whitespace between tags | Added and normalized | Removed |
| Output size | Larger | Smaller |
| When to use | Editing, debugging, review | Production, transfer |
| Indentation | 2 spaces, 4 spaces, or tabs | None |
| Rendered result | Identical | Identical |
The last row is the important one. Neither operation changes how the page looks. Only the whitespace a browser treats as insignificant changes. If a formatter ever alters your rendered output, that is a bug in the formatter, not a property of formatting.
Will formatting break my JavaScript, CSS, or preformatted text?
This is the question that separates a toy from a tool, and it is the reason I am picky about which formatter I use.
Certain elements hold content where whitespace and characters are significant and must not be touched. The WHATWG HTML Standard classifies script and style as raw text elements and textarea and title as escapable raw text elements. Inside them, a formatter must treat the content as opaque. If it tries to reindent the JavaScript in a script tag, it can shift the contents of a template literal, change a regular expression, or move a line inside a multi-line string, and now your code behaves differently. That is not a formatting change, that is a bug the formatter introduced.
The pre element is a related case. Its whole purpose is to preserve whitespace, so its text content is displayed exactly as written. A formatter that reindents inside <pre> visibly changes the page.
The toolz.dev formatter handles all of these by treating script, style, pre, textarea, and title as raw content: it re-indents the HTML around them but copies their inner text verbatim. Your code and preformatted text come out byte-for-byte identical. When I tested this while building it, the acceptance bar was simple: a <script> containing if(a<b){x=1} has to survive untouched, and it does. If you are working with markup that contains inline scripts or styles, this is the property to check before you trust any formatter.
Can a formatter handle broken or incomplete HTML?
Real HTML is rarely well-formed the way XML is, and a formatter that demands perfection is useless. Browsers are famously tolerant: the HTML parsing algorithm defines exactly how to handle omitted end tags and misnested elements, which is why a page with a missing </li> still renders fine. A good formatter borrows the same tolerance.
The most common case is optional end tags. HTML lets you omit the closing tag on elements like li, p, td, tr, and option, because the spec says an open li is implicitly closed when the next li begins. So <ul><li>a<li>b</ul> is valid, and the toolz.dev formatter applies these implied-close rules to produce <li>a</li> and <li>b</li> on their own lines, exactly as a browser would build the tree. A <p> is closed automatically when a block element opens inside it, because a paragraph cannot contain block content.
The second case is genuinely broken markup: a tag opened and never closed, or a stray closing tag with no matching open. The formatter closes anything left dangling at the end of the document and reports it as a warning, so you know the input was incomplete rather than silently guessing. Those warnings are often the fastest way to find the exact bug you came to fix.
Compare that behavior against a strict formatter, and against doing it by hand:
| Approach | Omitted end tags | Unclosed tags | Speed |
|---|---|---|---|
| Tolerant formatter (toolz.dev) | Applies implied-close rules | Auto-closes and warns | Instant |
| Strict XML-style formatter | Often errors out | Errors out | Instant when it works |
| Manual reindentation | You track it yourself | Easy to miss | Slow and error-prone |
I used to be in that bottom row, reindenting by hand and missing an unclosed div three times out of ten. The tolerant tool wins because real markup is messy and you want the mess surfaced, not rejected.
When should I use a formatter versus my editor?
If you own the file and it is in your project, your editor plus Prettier or an equivalent is the right home for formatting, because it runs on save and stays consistent across the team. I am not suggesting you replace that.
A browser-based formatter earns its place in the gaps that workflow leaves. You paste a fragment from a bug report and need to read it right now. You are on a machine that is not your dev box. You are looking at CMS output, an email template, or generated markup that never lived in a repo. You want to minify a single snippet without wiring up a build step. In all of those cases, opening a tab is faster than configuring a project, and the result is the same.
There is also the privacy angle, which is not a small thing. Because the toolz.dev parser runs entirely in your browser, markup that contains internal URLs, unreleased copy, API responses embedded in a template, or a customer's data never leaves your device. A lot of online formatters POST your input to a server to do the work. For anything from a work codebase, that is a data exposure you do not need to take. I care about this enough that it is a design rule for every tool on the site, which I wrote more about in the web developer toolkit and the guide to data privacy in online tools.
A practical workflow that has saved me hours
Here is the loop I actually run when a layout is misbehaving. Beautify the markup so the nesting is visible. Scan the indentation for the level that looks wrong, because a stray extra indent almost always means a tag that never closed. Read the formatter warnings, which frequently name the exact unclosed element. Fix it in the source. If the fragment is destined for production, minify it on the way back out. The whole cycle is a minute, and most of that minute is me reading, not fighting the tool.
The same loop works for content audits. When I check markup for accessibility or SEO, I beautify first so I can see the heading structure and landmark elements at a glance, then I pull specific pieces into other tools: converting a chunk to Markdown for documentation with the HTML to Markdown converter, or generating a comparison table with the Markdown Table Generator. Formatting is the step that makes the structure legible enough to work with. If you want the broader routine these tools fit into, the developer productivity tools guide lays it out.
Frequently asked questions
How do I format HTML online?
Paste your HTML into the input panel, choose Beautify, pick an indentation width, and click Format. The tool parses the tag tree and re-indents it, then lets you copy or download the result. All processing happens in your browser, so nothing is uploaded.
What is the difference between beautifying and minifying HTML?
Beautifying adds line breaks and indentation so the nesting is easy to read, which is ideal for editing and debugging. Minifying removes the insignificant whitespace between tags to produce a smaller file for production. Both keep the same rendered result; only the whitespace changes.
Will formatting change how my page looks?
No. The formatter only changes whitespace between tags, not the elements, attributes, or text. Content where whitespace is significant, such as pre, textarea, and inline text, is preserved, so a page renders the same before and after formatting.
Does the formatter reformat my JavaScript and CSS?
No. Content inside script and style tags is treated as raw text and copied verbatim. The tool re-indents the HTML around them but never touches the code itself, so template literals, regular expressions, and CSS values stay byte-for-byte identical.
Can it handle broken or incomplete HTML?
Yes, within reason. The parser is tolerant: it applies the same implied-closing rules browsers use for tags like li, p, and td, and it auto-closes tags left open at the end of the document. When it does, it shows a warning so you know the markup was incomplete.
Is it safe to format HTML that contains sensitive data?
Yes. The parser runs entirely in JavaScript in your browser. No network request carries your markup, nothing is stored, and the tool works offline once loaded. HTML holding internal links, API responses, or unreleased copy never leaves your machine.
What indentation options are available?
Beautify output supports 2 spaces, 4 spaces, or tabs. Two spaces is the common default for web projects, four spaces suits teams that prefer wider indentation, and tabs let each developer set their own display width in the editor.
How is an HTML formatter different from an HTML minifier?
A formatter has both directions in one tool: beautify to expand markup for reading, and minify to collapse it for shipping. A dedicated minifier only compresses. If you mainly need production compression, the HTML minifier focuses on that; if you switch between reading and shipping, the formatter covers both.
Format your markup with the free HTML Formatter. It runs entirely in your browser, keeps your scripts and preformatted content intact, and never uploads a byte.
