Indentation is a reading aid, not a repair
A beautifier moves whitespace around. That is the whole job. Tags stay in the order you wrote them, attributes keep their values, and a missing closing tag stays missing after the reformat. What changes is your ability to see the structure: five nested divs that arrived as one 3,000 character line become five indented lines, and the one with no partner becomes obvious.
This matters when you inherit output from a template engine, a CMS export, or a build step that stripped every newline. Reading that in a diff is hopeless. Format both sides first, then diff.
Whitespace is not always free
Reformatting looks harmless until an inline element shifts. Browsers collapse runs of whitespace into a single space, but they do render that one space, so a newline inserted between two inline elements becomes a visible gap:
<span>A</span><span>B</span><span>A</span><span>B</span>The second version renders as "A B" with a space between. Same problem hits inline-block grids, where that phantom space eats about four pixels per gap and breaks a four-column layout onto two rows. The formatter here keeps common inline tags on their parent line for that reason, though a hand-built component with unusual display rules still deserves a visual check after formatting.
Three places where added whitespace changes rendered output, not layout:
- <pre> blocks print every space and newline exactly as written. Indenting the contents indents the rendered text.
- <textarea> treats its contents as the default value. A newline after the opening tag turns into leading whitespace in the field.
- Template placeholders such as Blade, Twig, or Handlebars tags read as plain text to an HTML parser. Line breaks inside a control block survive the reformat, though the indentation the formatter adds rarely matches what the template outputs.
What each setting changes
| Setting | Effect on the output | Pick this when |
|---|---|---|
| 2 spaces | Two spaces per level of nesting | Deep component markup, where four spaces pushes lines off the screen |
| 4 spaces | Four spaces per level | Flat pages, or a codebase that already formats PHP and JS at four |
| Tabs | One tab character per level | A repo with an .editorconfig set to tabs, so the diff stays clean |
| Wrap width | Breaks lines past the limit, splitting attribute lists across lines | Elements carrying long class strings from a utility framework |
| Never wrap | One element per line no matter the length | You review in a wide editor and want attributes kept together |
| Indent head and body | Adds a level inside <html>, <head>, and <body> | Rarely. Most style guides leave those three flush at column zero |
| Embedded JS and CSS start | Sets the base column for <script> and <style> contents: one level in from the tag, aligned with the tag, or flush left | Flush left when a long script would otherwise sit five levels deep in a narrow editor |
Reading the depth meter
The bar strip under the panes counts how many elements sit at each level of nesting, and the line below it traces the path to the deepest one. Depth is the cheapest structural signal you have on a page you did not write.
Under six levels is ordinary. Past ten, you are usually looking at one of three things: a wrapper div added for every state a component has, a grid system nested inside another grid system, or a table layout that predates flexbox. None of the three break the page. All three make every future CSS override a fight, because each level adds descendant selectors that later rules have to outrank.
Beautify, minify, clean, or validate
Four jobs get confused with each other. Formatting adds whitespace for human readers and ships nothing to production. Minifying removes that whitespace again to cut transfer size. Cleaning deletes markup outright, such as the style attributes and empty spans that arrive when someone pastes from a word processor. Validating reports what breaks the spec and changes nothing at all.
The pairing worth knowing: format while you work, minify in the build. Never commit minified HTML to a repo and never serve the indented version. The round trip is lossless for markup, so a file survives both directions without harm.
Where this formatter stops
- No syntax repair. An unclosed <div> produces indentation that keeps drifting right. That drift is the signal, and fixing the tag is your job.
- No attribute sorting or rewriting. Quote style, attribute order, and duplicate attributes all pass through as written.
- Template syntax stays plain text. Blade directives, Twig blocks, and JSX expressions are not parsed as structure, so nesting inside them is not indented the way the rendered output nests.
- Embedded scripts follow general rules. Contents of <script> and <style> get reformatted, though the line breaks land where a generic formatter puts them, not where Prettier or your linter would. In a repo that enforces a style, format scripts with the JavaScript beautifier or your own toolchain and paste the result back.
- Large files slow the page. Formatting runs on the main thread, so a file past roughly 1 MB pauses the tab while the pass completes.
Everything runs inside your browser. The markup you paste never leaves the tab, which matters when the page you are debugging contains a customer name, an internal URL, or an API key someone left in a data attribute.
