Does formatting HTML affect how the browser renders it?

Almost never, for standard HTML. Browsers normalize whitespace in HTML — multiple spaces and newlines between elements collapse to a single space in flow content. The exceptions are elements where whitespace is significant: `pre`, `textarea`, and elements with `white-space: pre` applied via CSS. For everything else, formatting is purely for human readability and has zero effect on the rendered output.

Why doesn't the formatter handle inline elements the same as block elements?

Because they behave differently in the browser rendering model. Block elements (div, p, section, article, h1-h6) create line breaks and can be indented cleanly. Inline elements (span, a, strong, em) flow within text content, so adding newlines and indentation around them would actually change the text flow — adding unwanted spaces between words, for example. A good formatter treats inline elements conservatively to avoid introducing rendering differences.

Can I use an HTML formatter on JSX?

Not really. JSX looks like HTML but it isn't — it has different rules for self-closing tags (all void elements must be self-closed in JSX), uses className instead of class, and handles expressions with curly braces. An HTML formatter will likely mangle JSX. Use Prettier with the babel or tsx parser for JSX formatting — it understands JSX semantics properly.

My formatted HTML looks strange around script and style tags. Is that normal?

Yes. The content inside `script` and `style` tags is not HTML — it's JavaScript and CSS respectively. A proper HTML formatter should leave the contents of those tags alone (or hand them off to a JS/CSS formatter). If the formatter is indenting your JavaScript as though it were HTML markup, that's a sign of poor implementation. The ToolBox Hubs formatter handles this correctly.

What indent size should I use for HTML?

Two spaces. I know that's a take, but here's the reasoning: HTML nests deeply. A standard page might have html > body > main > article > section > div > p — that's already 7 levels of nesting. At 4 spaces per level, your content is pushed 28 characters in before you even start writing. At 2 spaces, the same depth is 14 characters, which keeps the structure visible without forcing everything off the right side of your screen.

Online HTML Formatter: Making Sense of Minified and Messy HTML

There's a specific kind of pain that comes from opening an HTML file from a CMS export, a third-party template, or a web scraper — and finding 40,000 characters of completely unindented, minified markup all on one line. You need to understand its structure. You need to find where the navigation ends and the main content begins. And right now, you can't.

This is what HTML formatters are for: taking that wall of characters and restoring it to something a human can read and navigate. The HTML Formatter at ToolBox Hubs does exactly this, and this guide covers when to use it, how it works, and what its limits are.

Why HTML Gets Minified in the First Place

Minification is a deliberate optimization. HTML files are served over the network, and every byte costs time. By stripping whitespace, newlines, and sometimes comments, a minifier can reduce an HTML file's size by 10-30% with zero functional change. At scale — millions of page views per day — that bandwidth saving matters.

The tools that do this (webpack, Vite, various build systems, CDNs) are not making your life difficult on purpose. They're doing their job. The minified file is the production artifact; the formatted version is for development.

The problem comes when:

You're inspecting a page you didn't build and you want to understand its structure
An email template from a vendor comes back as one impenetrable line
Your CMS exports minified HTML and you need to customize something
You're debugging a rendering issue and need to find a specific element quickly
A colleague sent you "the HTML" and it's clearly been through a build pipeline

In all of these cases, you need the inverse of minification: formatting. That's what we're doing here.

What Formatting Actually Does

At its core, an HTML formatter does two things: adds indentation to show nesting, and adds line breaks to separate elements.

Given this minified input:

<!DOCTYPE html><html><head><title>My Page</title></head><body><header><nav><ul><li><a href="/">Home</a></li><li><a href="/about">About</a></li></ul></nav></header><main><h1>Hello</h1><p>Some content here.</p></main></body></html>

A formatter produces something like:

<!DOCTYPE html>
<html>
  <head>
    <title>My Page</title>
  </head>
  <body>
    <header>
      <nav>
        <ul>
          <li><a href="/">Home</a></li>
          <li><a href="/about">About</a></li>
        </ul>
      </nav>
    </header>
    <main>
      <h1>Hello</h1>
      <p>Some content here.</p>
    </main>
  </body>
</html>

You can immediately see the page structure: the head, the header with navigation, the main content. The nesting tells you the document hierarchy. This is the entire point.

Notice how <li><a href="/">Home</a></li> stays on one line rather than being expanded to three lines. That's intentional — the anchor is inline content inside the list item, and splitting it across lines adds nothing useful. More on this in a moment.

Block Elements vs. Inline Elements: Why It Matters for Formatting

The distinction between block and inline elements is fundamental to how HTML formatters work, and it's worth understanding briefly.

Block elements create their own "block" of space: they start on a new line and take up the full width available. Examples: div, p, section, article, header, footer, h1 through h6, ul, ol, li, table. These are natural candidates for indentation — each one gets its own line, and its contents are indented beneath it.

Inline elements flow within text content, like words in a sentence. Examples: span, a, strong, em, code, img, button (in most contexts). These are trickier to format. If you have:

<p>Click <a href="/docs">the documentation</a> for more details.</p>

And the formatter naively adds newlines around the <a> tag:

<p>
  Click
  <a href="/docs">the documentation</a>
  for more details.
</p>

...those newlines become spaces in the rendered HTML, potentially changing the visual output. A well-implemented formatter knows to handle inline elements conservatively.

Void elements are a third category: elements that can't have children and therefore don't need closing tags. Examples: br, hr, img, input, meta, link. These get formatted on their own line if they're block-context elements, and they don't get closing tags added because the HTML spec explicitly prohibits them. If you see <br> rather than <br />, that's correct HTML5 — the self-closing slash is optional in HTML (though required in XHTML and JSX).

Real Scenarios Where This Is Useful

Reading Email Templates

HTML emails are almost universally written in terrible, table-based markup, then minified for delivery. When a vendor sends you an email template to customize, or when you're debugging why an email looks wrong in Outlook (a genuinely frustrating experience), the first step is making the HTML readable.

Paste it through the formatter. Find the table cell that corresponds to the section you're editing. Make your change. Re-minify if needed (though most email providers accept formatted HTML fine).

Analyzing Competitor Pages

Inspecting a page in browser DevTools shows you nicely formatted HTML because the browser's inspector formats it for you. But if you've downloaded the raw HTML via curl or a scraper, you get the production artifact — which is often minified.

The formatter lets you read the structure quickly. You can see what CMS or framework they're using from the class names and structure, understand their layout approach, and find specific elements you're curious about.

This is legal, common, and genuinely educational. The HTML is public; reading it is fine.

Debugging CMS Output

WordPress, Drupal, and similar systems often produce deeply nested, repetitive HTML markup. When something looks wrong visually and you need to find the element causing it, formatted HTML is dramatically easier to search through than a minified blob.

Copy the relevant section from DevTools, paste into the formatter, find the offending div or misplaced class. This is faster than navigating the inspector tree for complex layouts.

Reviewing Pull Requests with HTML Changes

If someone changed a template file that got auto-formatted or had its whitespace normalized, the diff might be unreadable — every line shows as changed because the indentation shifted. Running the old and new versions through the formatter with consistent settings gives you a clean, comparable output. Then you can use the Text Diff tool on the formatted versions to see actual semantic changes.

When NOT to Use a Formatter

The formatter is not always the right tool. Being clear about this saves confusion.

When you're working in a codebase with enforced formatting. If your project uses Prettier (which most modern projects do), you already have a formatter. Adding another one into the mix creates inconsistency and potential conflicts. Prettier handles HTML, JSX, and a dozen other formats. Stick with it for project files.

When exact whitespace matters. Inside pre tags, textarea elements, or elements styled with white-space: pre, whitespace is significant. Reformatting those would change the content. A good formatter won't touch those areas, but if yours does, stop using it for that purpose.

When you need to minify, not format. If your goal is to reduce file size, you want the HTML Minifier — the opposite of this tool. Formatting increases file size; minification reduces it.

When working with JSX. JSX has different rules than HTML. Use Prettier with the right parser. An HTML formatter will mishandle JSX class names, self-closing requirements, and expression syntax.

The Indentation Debate: 2 Spaces, 4 Spaces, or Tabs

I have an opinion here. HTML gets deeply nested fast. A completely normal page structure might look like:

html
  body
    main
      section
        article
          div
            p
              span

That's 8 levels deep before you've written a single word of real content. At 4 spaces per level, your text is 32 characters in. On a standard 80-character line, you have 48 characters left. Add an attribute or two and you're wrapping.

At 2 spaces, the same depth is 16 characters in — you have 64 characters of line space. Everything fits. The structure is still visible. The indentation still shows the hierarchy clearly.

Tabs make this even cleaner (because tabs are a single character in the file, and your editor can display them as any width you prefer). But tabs are divisive for cross-editor consistency.

My take: 2 spaces for HTML. It's the most common choice in the wild (Google's HTML style guide, most frontend frameworks), and it works at deep nesting levels where 4-space indentation starts to feel claustrophobic.

If your team has a different standard, use that. Consistency within a codebase matters more than any external opinion, mine included.

How the Tool Handles Edge Cases

A few behaviors worth knowing:

Comments are preserved. Conditional comments (<!--[if IE]>...), copyright notices, and build-time comments all stay in the output.

Script and style contents are untouched. The JavaScript inside a <script> tag is not HTML, and the CSS inside a <style> tag is not HTML. A correctly implemented formatter leaves those contents alone rather than trying to indent them as HTML markup. If you want to format the JavaScript, paste it into a JS minifier in reverse — or better yet, use an online JS formatter separately.

Malformed HTML is handled gracefully. Real-world HTML is often technically invalid: missing closing tags, improperly nested elements, attributes without quotes. The formatter tries to parse and format what it gets rather than refusing to process invalid input. Results may be imperfect, but you'll get something readable rather than an error.

Attribute order is preserved. The formatter doesn't reorder attributes. If the input has class before id, the output does too. This prevents unnecessary diffs when comparing with the original.

The Minification Reverse Problem

One thing to know: formatting doesn't always perfectly reverse minification. Minifiers sometimes make choices that aren't reversible, like:

Removing optional closing tags (</li>, </td>) — the browser can infer them, the minifier omits them, the formatter may not re-add them
Collapsing boolean attributes (disabled="disabled" to just disabled)
Normalizing attribute quote styles

This means if you format a minified file and then re-minify the formatted version, you might get slightly different output than the original minified file. That's fine — both are functionally equivalent. Just don't expect a perfect round-trip.

A Practical Workflow

Here's how I use the formatter when I get mystery HTML:

Paste the raw HTML into the HTML Formatter.
Scan the top-level structure first. What elements are at the root level under body? That tells you the page's rough layout.
Use the browser's find (Ctrl+F / Cmd+F in the formatted output) to jump to specific class names, IDs, or element types.
If I need to compare two versions, I format both and run them through a text diff tool to see the actual differences.
If I need to clean up my own HTML template, I format it, review the structure, then let my editor's Prettier config handle ongoing formatting from there.

The formatter is a starting point for understanding, not a replacement for proper development tooling.

The formatter works well as part of a set:

HTML Minifier — the reverse operation; reduces file size by stripping whitespace
HTML to Markdown — converts HTML to readable Markdown; useful for extracting content from pages
XML Formatter — same concept but for XML; useful for SVG files, RSS feeds, and API responses

If you're starting from formatted HTML and want to understand what a page actually does semantically, the HTML to Markdown converter can strip the tags and show you the content structure clearly — which is sometimes more useful than the raw markup.

The HTML Formatter is free and requires no account. Paste, format, done.