Indent HTML Properly

Standardising indentation across a legacy codebase

A team running a one-time formatting pass on a legacy codebase uses FixTools to indent every HTML file properly. The standardised output makes subsequent code reviews dramatically more productive because reviewers spend their attention on substance rather than whitespace. The team estimates the indentation pass paid back its setup time within the first two weeks.

Cleaning up automated build output for debugging

A developer indents the output of a build pipeline that produces compressed HTML to debug a layout regression. The properly indented version reveals a missing wrapper element that was the actual cause of the regression. The fix is in the upstream template, but identifying the issue required the formatted output to be readable first.

Preparing HTML for an external code review

A consultant indents the HTML of an internal application before sharing it with an external developer for review. The properly indented version produces a much more substantive review because the external developer can engage with the structure immediately rather than spending the first hour formatting in their head.

Onboarding a new developer to inherited code

A team indents all HTML files in a recently inherited project before adding a new developer to the project. The new developer ramps up significantly faster than they would have against the original inconsistent source, because the consistent indentation makes the structural patterns obvious from the first day.

Document the chosen indentation width in a project README or contributing guide so every contributor knows the expected style. Configure editor settings, pre-commit hooks, and CI checks to enforce the chosen width automatically. Documented and automated indentation removes the recurring discussion about formatting from code review, which lets reviewers focus on substance. The one-time effort of setting up the documentation and automation pays back every time a code review happens without the team relitigating the indentation choice.

When evaluating a new HTML generation tool, paste its output into a proper indenter and look at the result. Tools that produce structurally clean output indent into a sensible tree, while tools that emit malformed HTML produce indented output with obvious structural errors that suggest implementation bugs. This is a quick way to evaluate generation tools without writing extensive test cases, and it surfaces real issues that the tool documentation may not mention.

Some other HTML-aware tools, such as accessibility checkers and SEO auditors, produce more useful output when run against properly indented HTML. The tools work on the underlying DOM regardless of formatting, but their reports often include line numbers that are much more useful when the file is properly indented. Indenting first produces reports where each issue points to a clearly identifiable line in a readable file, rather than to a line in a wall of unformatted text.

A subtle but powerful use of proper indentation is detecting opening and closing tag mismatches that the parser tolerates but a human would consider errors. After indenting, scan the output for closing tags that appear at unexpected depths. These often indicate that an opening tag is missing somewhere upstream, or that a closing tag was placed at the wrong nesting level. The visual depth makes the mismatch obvious in a way that examining the raw source rarely does.

Choose two or four spaces for your project and apply it consistently across all HTML files. Consistency matters more than which width you choose.

Make proper indentation part of your pre-commit workflow so no improperly indented HTML enters the repository. A pre-commit hook automates this.

Pick formatters that produce the same output for the same input, regardless of who runs them. This eliminates whitespace conflicts in collaborative work.