HTML Formatting Rules: Indentation, Attribute Wrapping and Nesting

HTML Formatting Rules: Indentation, Attribute Wrapping and Nesting

If your HTML works but reads like a wall of tangled tags, the problem is usually formatting, not logic. This guide sets out practical HTML formatting rules for indentation, attribute wrapping and element nesting, so your markup stays readable when the file grows to a thousand lines.

Consistent formatting is not cosmetic. It changes how fast you spot an unclosed div, how easily a reviewer reads your diff, and how confidently you edit someone else's template at 11pm. The rules below are conventions rather than requirements — browsers ignore almost all of them — but teams that agree on them ship fewer bugs.

What Are the Core HTML Formatting Rules?

Four rules cover most day-to-day markup:

1. Indent one level per nesting depth. Each child element sits one step further in than its parent.
2. Use spaces, not tabs, and pick a fixed width. Two spaces is common; four is fine. Mixing the two is not.
3. Wrap attributes when a line gets long. Put each attribute on its own line once the tag stops fitting comfortably.
4. Close every element in the reverse order you opened it. Last opened, first closed.

Follow those four and most readability problems disappear before you need a linter.

Indentation: One Level Per Nest

Indentation exists to show structure at a glance. When a child element is indented relative to its parent, your eye can trace the tree without counting tags.

<article>
  <header>
    <h2>Release notes</h2>
  </header>
  <p>Version 4 ships today.</p>
</article>

The <h2> is two levels deep, so it gets two indents. The <p> is one level deep, so it gets one. No element should sit at the same indent level as its parent's sibling unless it actually is that sibling.

Two habits break this immediately. The first is indenting text nodes as if they were elements. The second is letting a deep block drift right until it runs off the screen. When you hit that point, the answer is usually to extract the block into a component or a partial, not to reduce the indent width.

Tabs or Spaces? Pick One and Enforce It

Both work. Mixing them does not. A file indented partly with tabs and partly with spaces renders differently depending on the editor's tab width, which makes diffs noisy and reviews slow.

Choose spaces if you want identical rendering everywhere. Choose tabs if you want each reader to set their own width. Either way, add an editor config file to the repository and a formatter to your workflow so the choice enforces itself.

Attribute Wrapping for Long Tags

A tag with three attributes fits on one line. A tag with nine does not. Attribute wrapping is the rule that keeps long tags readable.

<img
  src="/images/hero.jpg"
  alt="Team reviewing a design"
  width="1200"
  height="630"
  loading="lazy"
>

Three conventions are worth agreeing on:

• One attribute per line, indented one level past the tag name.
• The closing bracket on its own line for multi-line tags.
• A consistent attribute order, such as class, then id, then src or href, then everything else.

That last point matters more than people expect. A fixed order makes it obvious when an attribute went missing, because the gap is visible.

Nesting Rules That Prevent Broken Layouts

Nesting is where formatting rules meet actual correctness. Some elements cannot legally contain others, and the browser will silently restructure your markup if you try.

A <p> element cannot contain a block-level element such as <div>. The browser closes the paragraph early, and your layout breaks in a way that is hard to trace. Similarly, <ul> and <ol> should contain only <li> elements directly, and <li> may contain nested lists inside itself.

Keep nesting shallow where you can. Every extra wrapper adds a level of indentation, a level of CSS specificity to reason about, and one more place for a typo. If a container exists only to hold one child, question whether it needs to exist.

Deep nesting is rarely a formatting problem. It is usually a structure problem that formatting merely reveals.

How to Format an HTML File Step by Step

This sequence works whether you are tidying a single file or setting a standard for a team.

1. Open the file and locate the outermost element. Everything else nests inside it.
2. Set your indent unit. Two spaces, four spaces or one tab. Write it down.
3. Walk the tree from the top. For each element, indent its children exactly one level deeper than the element itself.
4. Reformat any tag longer than your line limit. Move each attribute onto its own line, indented one level past the tag name.
5. Apply a consistent attribute order across every tag in the file.
6. Check every opening tag has a matching close, in reverse order.
7. Run the file through a formatter and compare the result against your intended style.
8. Paste a section into a validator if the browser is rendering something you did not write.

Step eight is the one people skip. When markup looks correct but behaves oddly, validation usually names the element that is illegally nested. You can paste a fragment into a browser-based HTML formatter and validator to see the parsed structure rather than the source you typed.

How Should You Handle Indentation in Nested HTML Lists?

Nested lists are the classic test of indentation discipline, because the markup looks deeper than it is.

<ul>
  <li>
    Frontend
    <ul>
      <li>Markup</li>
      <li>Styling</li>
    </ul>
  </li>
</ul>

The inner <ul> belongs inside the <li>, not as a sibling of it. Indent it one level past that <li>, and the structure becomes self-documenting.

If your list renders with unexpected bullet levels or missing markers, the cause is almost always a <ul> placed as a direct child of another <ul>. Browsers tolerate it, but the resulting tree is not what you wrote, and CSS selectors will not match the way you expect.

Should You Reformat HTML Automatically or by Hand?

Reformat automatically for anything mechanical, and by hand for anything structural.

Mechanical changes include indent width, attribute wrapping, trailing whitespace and line endings. A formatter handles these consistently and without argument. There is no reason to spend review time on them.

Structural changes include deciding whether a wrapper element should exist, whether a component should be extracted, and whether an attribute belongs on this element or its parent. No formatter can answer those, and a tool that tries will produce markup that is tidy and wrong.

A reasonable split: run the formatter on save, and review structure in the pull request. That keeps diffs focused on decisions instead of whitespace.

Does HTML Formatting Affect Page Performance?

Not meaningfully. Extra spaces and line breaks add bytes to the file, and those bytes compress extremely well. Minifying your HTML saves far less than most people assume, particularly once transfer compression is in play.

The real performance argument for consistent formatting is indirect. Readable markup is easier to audit, so you notice a render-blocking tag or a duplicated script sooner. That is a maintenance benefit rather than a rendering one, and it is worth being honest about the distinction.

Whitespace between inline elements is the one place formatting can change output. A line break between two inline elements renders as a space in most contexts. If you are fighting a mysterious gap between two links, that is often the cause.

Common HTML Formatting Mistakes

• Indenting by eye instead of by level. Two elements at the same depth should share an indent, even if one has a longer tag name.
• Wrapping some long tags and not others. Inconsistency is worse than a rule you dislike.
• Reordering attributes in every commit. It buries real changes in noise.
• Nesting a <div> inside a <p>. The browser will close the paragraph for you.
• Formatting generated markup by hand. Format the template, not its output.

FAQ

How many spaces should I use to indent HTML?

Two spaces is the most common choice and keeps deep nesting readable on narrow screens. Four spaces is equally valid, especially in codebases shared with languages that use four. One tab is fine if your team agrees and your editor config enforces it. What matters is that the file uses one option consistently.

Should HTML attributes go on one line or separate lines?

Put them on one line while the tag stays short. Once a tag exceeds roughly eighty to one hundred characters, move each attribute to its own line, indented one level past the tag name. The threshold matters less than applying it consistently across the file.

Does indentation affect how HTML renders?

Almost never. Browsers collapse whitespace between block elements, so indentation has no visual effect there. The exception is whitespace between inline elements, where a line break can render as a visible space. That is a layout detail, not a formatting rule.

Can I nest any element inside any other element?

No. Several elements have content models that restrict what they may contain. A <p> cannot hold a block-level element, and a <ul> should contain only <li> children directly. Browsers repair invalid nesting silently, which is why the rendered page can differ from your source.

What is the fastest way to fix badly formatted HTML?

Run it through a formatter first, then validate it. Formatting fixes indentation and attribute wrapping in one pass. Validation catches the nesting errors that formatting cannot detect, because invalid nesting is legal-looking text that produces a different tree.

Conclusion

Good HTML formatting rules come down to three habits: indent one level per nesting depth, wrap long tags one attribute per line, and nest elements only where the content model allows it. None of them change how the browser renders your page, and all of them change how quickly you find the bug when something breaks.

Pick your conventions, enforce them with a formatter, and review structure rather than whitespace. If you need to check a fragment without setting up a build step, paste it into the online tools collection and inspect the parsed result directly.