Free · Fast · Privacy-first

Format HTML with Proper Indentation

Proper indentation is the single biggest factor in HTML readability, ahead of comments, naming conventions, or any other style consideration.

⚡

2-space and 4-space indent options

🔒

Correctly indents all nested elements

✨

Handles deeply nested tables and lists

⚡

Free with no usage limits

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this HTML Formatter to your website

Drop the HTML Formatter into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/html/html-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/html/html-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Indentation Standards in HTML: Why the Details Matter

Indentation in HTML is not decorative. It communicates the document hierarchy directly through visual structure. When every child element is indented exactly one level deeper than its parent, a developer scanning the file can determine the nesting depth of any element at a glance without reading any tag names. This is why indentation conventions exist: not to satisfy an arbitrary style preference or to make the code look pretty, but to encode structural information in a form that humans can absorb at reading speed. When indentation is inconsistent or missing, the file hides its own structure, and every edit requires mentally re-parsing the whole document to avoid breaking a nesting relationship. This cognitive overhead compounds across every reader and every read.

FixTools formats HTML indentation by parsing the document tree using a standards-compliant HTML5 parser, then re-emitting each element with a prefix of spaces equal to its depth in the tree multiplied by the indent unit you select. Block-level elements get their own lines so the structure is visible vertically. Inline elements are kept on the same line as their surrounding text content to avoid introducing whitespace that could affect rendering through the inline-block whitespace gap. Void elements such as img, br, hr, and input are placed on their own lines at the correct depth without adding closing tags. The formatter also converts any existing tab characters to spaces and normalises mixed indentation before applying the chosen width, so the output is uniform regardless of how messy the input was.

The two-space versus four-space debate has practical consequences that go beyond personal preference. Two-space indentation keeps deeply nested HTML within the typical eighty to one hundred twenty character line length used by most style guides, which means content rarely wraps or scrolls horizontally. Four-space indentation makes each level more visually distinct, which is helpful in documentation, in teaching contexts, or when the audience is less familiar with HTML nesting and benefits from the larger visual jump between levels. Neither is universally superior. The right choice depends on your team, your project type, your typical nesting depth, and your existing conventions. Pick one, document it, and apply it consistently.

A common pattern that emerges in mature codebases is using two-space indentation for the project source and four-space for documentation outputs that include code examples. This gives developers the compact source they need to scan quickly while giving documentation readers the larger visual jumps that help them follow the structure without prior HTML expertise. The build pipeline handles the conversion, so neither audience has to compromise. This pattern works well for design system documentation, API documentation that includes HTML examples, and tutorials embedded in product help centres.

HTML Living Standard (WHATWG)Google HTML/CSS Style Guide

How to use this tool

💡

Paste your HTML, choose your indent width, and click Format. Every nested element will be indented one level deeper than its parent.

How It Works

Step-by-step guide to format html with proper indentation:

1
Paste your HTML
Paste the HTML with inconsistent indentation into the input panel. The parser accepts any length of input and any current state of indentation, including tabs, mixed widths, or no indentation at all. Nothing about the input form matters because everything will be normalised in the next step.
2
Select indent size
Choose two-space or four-space indentation based on your project standards. If your team has an .editorconfig file or documented style guide, follow whatever it specifies. Two-space is the modern default for new projects and matches Prettier and most popular style guides.
3
Format
Click Format to run the parse and re-serialise step. Every child element is indented one level deeper than its parent, consistently throughout the document, and any existing tabs or mixed indentation are replaced with the uniform width you selected.
4
Copy the indented HTML
Copy the result with the clipboard button and paste the properly indented code back into your editor. The original input remains in place if you want to re-run with a different indent width to compare the two options before deciding which version to commit.

Real-world examples

Common situations where this approach makes a real difference:

Fixing indentation after a merge conflict

Resolving a merge conflict in HTML often destroys indentation as the conflict markers get removed and the surrounding lines stay where the merge tool placed them. Format the resolved file to restore proper nesting before committing, which gives reviewers a clean diff to evaluate and prevents the indentation drift from accumulating across future merges.

Converting tabs to spaces

A file with tab-based indentation needs to be converted to two-space before joining a project that enforces spaces. The formatter handles the conversion automatically in a single pass, replacing every tab with the appropriate number of spaces based on its depth in the tree, which is more reliable than a naive find-and-replace that does not account for nesting context.

Inheriting code from an external agency

When a project transitions from an external agency to an in-house team, the inherited HTML often uses indentation conventions that do not match the in-house standards. Running every file through the formatter with the in-house indent width brings the entire codebase into compliance in a single batch commit, which is faster and more reliable than asking developers to gradually convert files as they touch them.

Cleaning up a draft prototype

A rushed prototype written during a hackathon or sprint often has inconsistent indentation because the developer was focused on functionality. Before the prototype graduates to production code, format every file to bring the indentation into compliance, and the resulting code is significantly more reviewable for the team members who will take it forward.

When to use this guide

Use this when your HTML has inconsistent or missing indentation that makes the nesting structure impossible to follow at a glance.

Pro tips

Get better results with these expert suggestions:

Use indentation depth as a complexity signal

When you format HTML and see elements indented more than six or seven levels deep, treat that as a signal that the markup is over-nested rather than as a normal state. Consider whether some wrapper divs can be removed, whether the layout can be flattened with CSS grid or flexbox, or whether the structure represents an unnecessary abstraction. Indentation makes complexity visible in a way that nothing else does, and using it as an architectural signal rather than just a style consideration is one of the highest-leverage habits a front-end developer can adopt.

Keep indentation consistent when hand-editing after formatting

After formatting, if you manually add new elements to the file, match the indentation of adjacent siblings exactly rather than relying on your editor's auto-indent which may have a different configuration. A single misaligned element in an otherwise consistently formatted file is easy to miss in review and hard to find later when debugging. The discipline of matching indentation manually as you edit is faster than re-running the formatter every time, and it builds the habit of reading indentation as meaningful information.

Format the head section separately from the body for large files

For very large HTML pages, paste and format the head section and the body section separately rather than trying to format the whole document in one pass. This makes reviewing each section easier because you can focus on one logical region at a time, and it avoids very long output that fills the entire formatter panel and makes it hard to find specific elements. After formatting each section independently, reassemble them in your editor with the correct structure preserved.

Match your HTML indentation to your CSS indentation

If your CSS uses two-space indentation, which is common in most modern style guides, use the same width for your HTML so the two file types feel consistent when you move between them. Consistent indentation across all file types in a project reduces the cognitive switching cost of moving between files, which is a small saving per switch but a meaningful saving across a working day spent jumping between markup and styles. Same applies to JavaScript and TypeScript: pick one indent width and apply it across all your source files.

2 spaces for web projects, 4 for docs

Two-space indentation is standard in most modern front-end projects. Four-space is often preferred in documentation and tutorials for better visual clarity.

Watch deeply nested tables

HTML tables inside divs can produce 6-8 levels of indentation. Consider breaking very deep structures into components to keep indentation manageable.

Tab vs space consistency matters

Always use spaces (not tabs) for HTML indentation in shared projects. Mixtures of the two cause editors to render wildly different visual indentation widths.

FAQ

Frequently asked questions

Yes. Selecting a space-based indent option will convert any existing tab characters to the chosen number of spaces, and the output will use only spaces with no remaining tabs. This is important for projects where editors and continuous integration tools are configured to treat tabs as errors, where mixed indentation produces inconsistent visual results across different editor configurations, or where the project style guide explicitly requires spaces. The conversion is context-aware, meaning each tab is replaced with the correct number of spaces for its depth in the tree.

Two spaces is the most widely used indent width in modern web development. Google's HTML and CSS Style Guide explicitly recommends two-space indentation, Prettier defaults to two spaces for HTML and most other file types, and the majority of open-source front-end projects on GitHub use two spaces. Four spaces is common in older codebases, in documentation contexts where extra visual separation helps readers, and in projects with strong historical PHP or Python conventions where four-space is the language norm.

Indentation encodes the parent-child relationship between elements visually, which lets a reader determine the nesting depth of any element at a glance. When indentation is correct and consistent, the structure of the document is readable from the indentation pattern alone without reading any tag names. Without consistent indentation, you must read every opening and closing tag to understand the structure, which is error-prone, slow, and exhausting across a long working session. The compounded productivity cost of unindented HTML across an entire project is substantial.

Whitespace including indentation between block-level elements has no visual effect in browsers because block layout collapses all such whitespace during rendering. Between inline elements, however, whitespace can produce a small visible gap, sometimes called the inline-block whitespace problem. The FixTools formatter handles inline elements carefully by keeping them on the same line as their surrounding text, which avoids introducing the problematic whitespace. For practical purposes, indentation is purely a developer-facing feature with no rendering consequences.

The formatter normalises all indentation to a single consistent style based on your selected width. Tabs are converted to the chosen number of spaces, inconsistent space counts are replaced with the uniform indent width, and the output is clean and uniform regardless of what the input contained. This is exactly what you want when bringing a project with multiple historical indentation styles into a single consistent state, and the entire normalisation happens in a single pass that you can apply file by file or batch across the project.

Use two spaces for a new project unless you have a specific reason to do otherwise. Two spaces is the default for Prettier, matches the Google Style Guide, keeps deeply nested HTML within readable line lengths, and is the most widely used convention in modern web development. Four spaces is a valid choice for documentation-focused projects, teams with a strong existing four-space preference from other languages such as Python or PHP, or contexts where the wider visual jump between levels meaningfully helps readers who are less familiar with HTML nesting.

The formatter indents the opening and closing script and style tags at the correct depth in the document structure, but the content inside these tags is preserved exactly as written and is not re-indented. This is the correct behaviour because reformatting script content with HTML rules would frequently produce invalid JavaScript, particularly when the script contains template literals with embedded HTML-like content. If you also want to format your inline JavaScript or CSS, use a dedicated JavaScript or CSS formatter as a separate step.

FixTools currently supports two-space and four-space indentation, which together cover the two standard conventions used in essentially all modern web projects. If your project requires a different width such as three spaces or eight spaces, use the four-space output as a starting point and apply a simple post-processing find-and-replace step in your editor to adjust the indent width further. In practice, almost no real-world projects use non-standard indent widths because the cost of going off-convention exceeds any benefit.

Commit an .editorconfig file at the project root with indent_style set to space and indent_size set to your chosen number. Most modern editors and IDEs read .editorconfig automatically, so this single file enforces the convention across the team without requiring per-developer setup. For automated enforcement, add a Prettier configuration with matching settings and run Prettier as a pre-commit hook or continuous integration check so non-compliant files are caught before they reach the main branch.

Indentation has no direct effect on accessibility because screen readers parse document structure rather than visual formatting. However, indentation has a meaningful indirect effect: properly indented HTML makes it dramatically easier for developers to spot and fix accessibility issues such as missing alt attributes, incorrect heading order, missing form label associations, or improperly nested interactive elements. Many accessibility audits begin with a formatting pass for exactly this reason, because the time saved on audit findings exceeds the time spent formatting.