Prettified HTML is easier to read, easier to diff, and much easier to debug than a single minified blob. The HTML Prettifier walks your markup tag by tag, re-indents children one level deeper than their parents, and breaks long inline runs onto separate lines. The contents of <pre>, <textarea>, <script> and <style> tags are kept byte-for-byte intact — those tags treat whitespace as content, so changing it would change what the page renders.
The formatter tokenises the input into open tags, close tags, self-closing tags, and text runs, then walks the token list with a depth counter — incrementing on open tags, decrementing on close. Each token is written on its own line at depth × indent. Whitespace-sensitive blocks are detected by tag name (pre, textarea, script, style) and emitted verbatim, so embedded code and pre-formatted text don't get mangled.
<pre>, <textarea>, <script>, <style> contents<pre> blocks?It shouldn't be re-indented at all. The prettifier deliberately leaves <pre>, <textarea>, <script> and <style> contents untouched — those tags treat whitespace as content, so adding indentation would change what the page actually displays.
Yes — flip the mode toggle and click Run again on the same input. The prettify and minify passes are exact opposites, so you can round-trip without losing anything except whitespace.
No — minify before deploy and prettify when you're reading or editing. Indented HTML is easier on humans; minified HTML downloads faster for browsers. Most projects keep prettified source in git and minify in the build step.
No, this tool only re-indents — it does not validate or repair markup. If your HTML is malformed (unclosed tags, mismatched nesting), the indentation will reflect the broken structure. Use an HTML validator first if you suspect parse errors.
Pair with the HTML Minifier for the reverse pass, or the HTML to Plain Text Converter when you only need the visible content.