Free · Fast · Privacy-first

HTML Formatter with 2-Space Indentation

Two-space indentation is the de-facto standard for modern HTML codebases, used by Prettier, the Google HTML and CSS Style Guide, the Airbnb style guide, and the majority of open-source front-end projects you will encounter.

⚡

Strict 2-space indentation

🔒

Compatible with Prettier defaults

✨

Consistent across all element types

⚡

Free and instant

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.

Why 2-Space Indentation Became the Modern HTML Standard

Two-space indentation emerged as the dominant convention in front-end development largely because of two influential style guides published by major engineering organisations: Google's HTML and CSS Style Guide, and the Airbnb JavaScript Style Guide. Both of these documents codified two-space indentation as the default, and their adoption across the open-source ecosystem meant that any new developer learning modern web development encountered two-space code far more often than four-space. When Prettier launched as an opinionated code formatter and was rapidly adopted across the JavaScript ecosystem, it reinforced the convention by defaulting to two-space indentation for every file type it supports, including HTML. Today, the majority of open-source front-end projects, component libraries, and framework starter templates use two-space indentation, making it the safe default for any new project.

The technical reason two-space indentation works well for HTML specifically is line length management. HTML structures can nest deeply: a responsive layout might wrap a grid container around a card component, which wraps a content section, which wraps a paragraph, which contains a link with several attributes. With four-space indentation, the paragraph text starts sixteen spaces from the left margin even before any attributes are added, which is far enough to cause horizontal scrolling in editors with narrow panels or in side-by-side diff views. Two-space indentation keeps deeply nested content within the common eighty to one hundred twenty character line length limit, reducing the need to scroll or wrap lines and making the code comfortable to read in a standard editor configuration. FixTools applies exactly two spaces per nesting level with no variation, which means the output is predictable and matches what other two-space tools produce.

The main trade-off of two-space indentation is that the visual distinction between levels is subtle for readers who are unfamiliar with the code. A developer new to a two-space codebase, or a non-developer reviewing HTML for content changes, may find it harder to quickly identify parent-child relationships than in a four-space file where the visual jump between levels is larger. For documentation aimed at non-developers, for teaching contexts where the audience is learning HTML for the first time, or for printed code samples where the visual jump matters more than line length, four-space is sometimes preferred even when the underlying project uses two-space. This is a reasonable pattern and many teams adopt it deliberately as a translation step between developer source and end-user documentation.

A practical advantage of two-space indentation is round-trip compatibility with the broader ecosystem. If you open-source a project, contribute to an open-source library, or accept pull requests from external contributors, two-space output works without friction because it matches what the contributor's formatter is likely configured to produce. Choosing a non-default indent width can subtly increase the friction of every external contribution because every contributor needs to either match your width or accept that their formatter will fight your convention. Picking the ecosystem default reduces this friction to zero.

Google HTML/CSS Style Guide Prettier HTML Formatting Docs

How to use this tool

💡

Paste your HTML and click Format. The output uses exactly 2 spaces per indentation level, matching the default used by Prettier and most modern frameworks.

How It Works

Step-by-step guide to html formatter with 2-space indentation:

1
Paste your HTML
Paste any HTML into the input panel of the HTML Formatter. The tool accepts fragments, partial templates, and complete documents with the same logic, and there is no length restriction beyond the practical memory limit of your browser tab.
2
Select 2-space indentation
Choose the two-space option in the indent selector. This setting produces output that matches Prettier defaults, the Google Style Guide, and the convention used by the majority of modern front-end projects.
3
Click Format
Click Format to run the parse and re-serialise step. The output is formatted with exactly two spaces per nesting level, applied consistently to every block element from the outermost wrapper down to the deepest leaf.
4
Copy the result
Copy the two-space-indented HTML with the clipboard button and use it in your project, pull request, documentation, or anywhere else you need clean two-space output. The original input remains in place in case you want to re-run with a different setting.

Real-world examples

Common situations where this approach makes a real difference:

Reformatting files before adding to a Prettier-controlled repo

Pre-formatting HTML with two-space indent before committing means that Prettier's pre-commit hook will not flag the files with formatting diffs, which keeps the commit history clean and avoids the awkward pattern where every contribution starts with an automatic Prettier reformat commit before any substantive change.

Aligning a freelancer's deliverable with project standards

A contractor delivers HTML with four-space tab indentation, which does not match the in-house project standard of two-space spaces. Pasting the deliverable into the formatter with two-space selected standardises every file in minutes, making the deliverable ready for review without manual conversion work.

Standardising design system component examples

A design system documentation site presents HTML examples for every component. Running every example through the formatter with two-space indent before publishing ensures the documentation feels consistent, which improves the perceived quality and reduces follow-up questions from consumers of the library who notice and ask about inconsistencies.

Converting legacy four-space code to modern conventions

An older PHP project with four-space HTML indentation is being modernised to match the conventions of newer projects in the same organisation. Running every file through the formatter with two-space selected produces a single batch conversion commit that brings the legacy code into alignment without weeks of manual editing.

When to use this guide

Use this when your project enforces 2-space HTML indentation (Google Style Guide, most front-end frameworks) and you need to normalize existing files.

Pro tips

Get better results with these expert suggestions:

Set tabWidth: 2 in your Prettier config to match FixTools output

If your project uses Prettier for JavaScript, TypeScript, or CSS, adding tabWidth two to your .prettierrc ensures that when Prettier runs on HTML files, the output matches what FixTools produces. Consistency across all formatters in a project eliminates the formatting conflicts that arise when different tools produce different output for the same input, and it means a developer can use either tool depending on the situation without the project drifting between two slightly different styles.

Use 2-space output to spot over-nesting early

When code formatted at two spaces still reaches the right margin of your editor, the nesting is almost certainly too deep and the structure should be examined. Two-space indentation is a lighter warning signal than four-space because the jumps are smaller, but it still flags structures that should be refactored or broken into smaller components. A line that exceeds the column limit at two-space depth indicates either over-nested wrappers or an attribute list that has grown beyond what one element can reasonably carry.

Add indent_size = 2 to .editorconfig before onboarding contributors

New contributors set up their editors with whatever defaults their installation provides, which may or may not match your project. An .editorconfig file with indent_size two and indent_style space ensures auto-indent works correctly from their very first commit, without requiring any manual editor configuration or out-of-band setup documentation. Most modern editors read .editorconfig automatically, so the single file removes a friction point for every new team member.

Make indent conversion a dedicated commit

When converting from four-space to two-space across an entire codebase, commit the change in isolation with a clear message such as "chore: convert HTML indentation from 4-space to 2-space". This keeps formatting changes out of git blame results for functional lines, makes the history searchable, and gives future readers a clear answer when they wonder why every file changed on the same day. Many version control workflows let you mark cosmetic commits as ignorable for blame purposes, which further reduces long-tail noise.

Match your Prettier config

If your project uses Prettier, the 2-space HTML output from FixTools matches Prettier's default, making it easy to maintain consistency without running the full build pipeline.

2 spaces keeps line length manageable

On deeply nested structures, 2-space indentation prevents lines from exceeding the standard 80-120 character limit, reducing the need for horizontal scrolling.

Commit a .editorconfig

Once you've decided on 2-space indentation, add an .editorconfig to your project so all team editors enforce it automatically.

FAQ

Frequently asked questions

Two-space indentation is the default for Prettier, matches the Google HTML and CSS Style Guide, and is the most widely accepted convention in modern web development. It keeps deeply nested HTML within a comfortable line length so content rarely wraps or scrolls horizontally, it matches the indent width used by most popular open-source projects so your code feels familiar to external contributors, and it is the recommended starting point for any new project unless you have a specific reason to choose otherwise. The compounding benefit of matching the ecosystem default is hard to overstate for any project that interacts with the broader web development community.

Yes. Paste your four-space indented HTML and select two-space indentation in the indent selector. The formatter converts the indentation automatically, replacing every depth-appropriate group of four spaces with two spaces at the correct depth in the document tree. The conversion is context-aware, meaning it respects the parsed structure rather than doing a naive find-and-replace that might miscount in cases where the original four-space indentation was inconsistent.

No. Browsers ignore whitespace indentation entirely when rendering HTML between block-level elements. Two-space, four-space, and even fully minified HTML all render identically because the browser strips and normalises whitespace during layout. The choice of indent width only affects developer experience in a text editor and has no consequences for what visitors see when they load the page in any browser, on any device, at any screen size.

Google's HTML and CSS Style Guide explicitly recommends two-space indentation as the project default. Prettier defaults to two spaces for HTML and most other file types it supports. The Airbnb JavaScript Style Guide also uses two spaces, and many teams extend the Airbnb convention to HTML for consistency across their entire codebase. The Standard JS style and most other widely adopted modern style guides converge on two-space indentation as well.

Yes, for line length management. With two-space indentation, a structure nested eight levels deep uses sixteen leading spaces before any content begins. With four-space, the same depth uses thirty-two spaces, which often pushes content beyond the standard eighty-character line limit and forces horizontal scrolling or line wrapping. Two-space is the practical choice for any codebase that uses moderately deep nesting, which is essentially every real-world HTML project beyond the simplest static pages.

Add an .editorconfig file at the project root with indent_style set to space and indent_size set to two. Most modern editors and IDEs read this file automatically and apply the settings to any file in the project, which means new contributors get the right behaviour from their very first edit without needing per-developer setup. For automated enforcement at the commit level, configure Prettier with tabWidth two in your .prettierrc and add Prettier as a pre-commit hook or continuous integration check.

FixTools aims for Prettier-equivalent output for the vast majority of HTML patterns, and in practice the two tools produce indistinguishable results for normal markup. Minor differences may exist for edge cases involving inline elements mixed with text in unusual ways, deeply nested template syntax, or specific framework conventions that Prettier handles with plugin-specific rules. For typical project HTML, the output is functionally identical and the two tools can be used interchangeably.

Yes, and it is the recommended approach. Tailwind HTML often has long class attribute values that contain many utility class names. Using two-space indentation keeps the overall line length more manageable compared to four-space, which makes Tailwind-heavy HTML easier to read in a standard editor window. Some teams pair two-space indentation with a Prettier plugin that sorts Tailwind classes, which together produce HTML that is both compact in indentation and consistent in class ordering.

Yes. Email HTML with its nested table layouts benefits significantly from two-space indentation because the deep nesting common in email templates would otherwise push content far to the right with four-space. Two-space keeps the structure scannable even at six or seven levels of nesting, which is common in templates that wrap content in centring tables inside outer tables inside body tables. Most modern email frameworks default to two-space output for exactly this reason.

Technically yes, but it is strongly discouraged. Mixed indent widths within a single project create noisy diffs, confuse contributors, and make linting rules ineffective because no single rule can describe valid output across the whole codebase. Pick one width per project and apply it uniformly. If you need different output for documentation versus source, handle that as a build step that converts the source indent width rather than maintaining two indent conventions in the same files. Two-space indentation is the most common convention in JavaScript ecosystems, including React, Vue, and Angular projects.

Two-space indentation became the standard in JavaScript ecosystems around 2015 when style guides from Airbnb, Google, and Standard JS converged on it. The reasoning: HTML often nests deeply (5+ levels for typical React components), and 4-space indentation pushes content too far right on standard terminals or code review screens. Two spaces also align nicely with JSX attribute spacing. Most popular frameworks (React, Vue, Next.js) use 2 spaces in their own documentation. Some Python-influenced teams still prefer 4 spaces for visual parity with their Python code, but 2 spaces is dominant in modern web development.