Free HTML Formatter & Beautifier

What HTML Formatting Actually Does

HTML formatting (also called "beautification" or "pretty-printing") is the inverse of minification. A formatter takes HTML in any form (minified production output, copy-pasted from a browser inspector, generated from a template engine, or just messily written by hand) and re-emits it with consistent indentation, line breaks between block elements, and a predictable visual structure. Browsers ignore the extra whitespace at parse time, so formatting changes how the source looks but never how the page renders. Why bother? Because human eyes parse indented hierarchy faster than visually flat tag soup. Code review, debugging, learning HTML structure, handing off markup to another developer, comparing two versions for changes, all become substantially easier when the document tree is visually obvious from the indentation.

The five real-world workflows where a formatter earns its place: (1) minified production HTML pasted from a browser's "View Source" or DevTools "Copy outer HTML" back into a debugger; (2) HTML extracted from a CMS textarea where the WYSIWYG editor produced visually clean output but messy source; (3) debugging template engine output (Jinja, Twig, Handlebars, ERB) where the rendered HTML doesn't match what you expected; (4) converting auto-generated HTML (from React server-side rendering, Pandoc, document converters) into a readable form for code review; (5) cleaning up email-template HTML before submitting to a marketing platform that may strip your formatting on import.

The Major HTML Formatters

js-beautify (Einar Lielmanis, 2007 onwards) is the long-standing JavaScript-ecosystem formatter, handles HTML, CSS, JavaScript and JSON with a single library. The HTML formatter is what powers the public face of beautifier.io and what historically backed dozens of "format HTML online" sites. Prettier (James Long, 2017) is the opinionated formatter that came to dominate the modern frontend ecosystem; HTML support landed shortly after launch. Prettier's design philosophy is "almost no configuration", one indent style (2 spaces by default), one line-width target (printWidth: 80), one set of attribute-wrapping rules. The trade-off is consistency across teams without bikeshedding; the cost is less personal flexibility. HTML Tidy (Dave Raggett at W3C in 1997, now maintained by HTACG) is the original, it predates the web's modern formatter scene and was originally designed to clean up old, broken, deprecated HTML from the late 1990s. Tidy still ships on macOS by default (/usr/bin/tidy) and on most Linux distributions; less commonly used in 2026 but still respected for its rigour. In a modern workflow, Prettier is the default for new projects, integrated into VS Code (the default formatter for HTML files), JetBrains IDEs, and pre-commit hooks via Husky + lint-staged. This tool is for the cases where you don't have a build pipeline running Prettier, paste, format, copy out.

Indentation Conventions

Three indentation styles compete in modern HTML. 2 spaces is the modern web default, used by GitHub's HTML/CSS Style Guide, the Google HTML/CSS Style Guide, Prettier's default, the WHATWG style examples, and most npm-published front-end packages. The argument: HTML nests deeply (a typical component might be 6-10 levels of indentation), and 2 spaces keeps lines from running off the right edge of an 80-column display. 4 spaces is the older Java / Microsoft tradition that survives in some legacy projects and the PSR-12 PHP standard; produces visually clearer hierarchy at the cost of horizontal space. Tabs are favoured by the Linux kernel community, some Go projects, and developers who argue that tab characters let each viewer set their own visual width preference. The "tabs vs spaces" argument is older than most readers and unwinnable; the practical answer is to pick one per project and have your formatter enforce it. This tool offers all three.

Inline vs Block Elements, The Whitespace Trap

The single biggest gotcha in HTML formatting is the distinction between block-level and inline elements. Block elements (<div>, <p>, <section>, <article>, <ul>) flow as paragraph-style blocks; whitespace between them is rendered as nothing visible, so a formatter can freely add line breaks and indentation around them. Inline elements (<span>, <a>, <strong>, <em>, <code>) flow within text; whitespace between them IS rendered. Consider <p>Hello <strong>world</strong>!</p>: the space between "Hello" and the opening <strong> is a real space character that will appear between the words. If a naive formatter breaks that line and indents <strong> on its own line, the rendered output silently gains visible whitespace and may now read "Hello world" with an extra space. Worse, formatters that strip whitespace between inline elements can fuse adjacent words: "Helloworld" with no space. The "preserve inline tags" option (default-on here) tells the formatter to keep inline elements on the same line as their surrounding text, the safe behaviour for most real-world HTML.

Protected Content, pre, textarea, script, style

Four HTML elements have whitespace-significant content that must not be reformatted: <pre> displays text exactly as written including line breaks and spaces; <textarea> initial content survives whitespace; <script> contains JavaScript whose semantics depend on whitespace (or at least where adding indent would corrupt the source); <style> contains CSS that should be reformatted by a CSS-aware formatter, not an HTML one. Production HTML formatters (Prettier, Tidy, js-beautify) detect these elements and skip reformatting their content. Honest disclosure for this tool: the implementation is hand-rolled rather than wrapping a production library, and the inline-vs-block + protected-content handling is conservative but not perfectly fault-tolerant. If you run heavy production HTML through it and the output looks wrong inside a <pre> block or breaks a script, the safer option is to use Prettier locally (it's a one-command install: npm install -g prettier, then prettier --parser html input.html). For ordinary template and component-level HTML, this tool handles the common cases.

Attribute and Self-Closing-Tag Conventions

HTML attributes have their own formatting choices. Short attribute lists fit on one line (<a href="/about" class="link">); long lists wrap one-per-line, often with the closing > on its own line. Prettier's printWidth: 80 default triggers wrapping when a line would exceed 80 characters, which is the modern convention. Some teams enforce attribute order (class first, then id, then data-*, then ARIA, then event handlers); most formatters respect existing attribute order rather than reorder, since reordering can change behaviour in subtle cases (CSS specificity, JavaScript class lookups). Self-closing tags: HTML5 doesn't require the trailing slash on void elements (<br>, <hr>, <img>, <input>, <meta>, <link>: there are 14 void elements total in HTML5), but XHTML and JSX do (<br />). Formatters either preserve the slash if present, drop it (HTML5-clean), or add it (XHTML-friendly) depending on configuration. This tool follows the input, if your source uses <br />, the output keeps it; if you use <br>, the output keeps that.

Common Use Cases

• Code review. Clean up HTML extracted from a colleague's email or a PR before reviewing it line by line.
• Debugging. Properly indented code makes it instantly visible where a missing closing tag broke the structure.
• Template cleanup. Reformat HTML generated by Jinja, Twig, Handlebars or any template engine to inspect what's actually being sent to the browser.
• Developer handoff. Hand a backend developer a frontend snippet that's actually readable rather than minified one-liner soup.
• Learning HTML structure. Indented hierarchy makes the document tree visually obvious, useful when learning HTML or analysing an unfamiliar codebase.
• Email template inspection. Email-template builders (Mailchimp, ConvertKit) often produce inline-styled HTML that's hard to read; formatting it makes the structure visible before submitting changes.

The Modern Pipeline, Prettier on Save

For projects with a build pipeline, the 2026 default is Prettier running on save in your editor and on every commit via a pre-commit hook. VS Code ships Prettier as the default HTML formatter when the extension is installed; trigger with Format Document (Shift+Alt+F on Windows/Linux, Shift+Option+F on macOS) or enable "editor.formatOnSave": true in settings. JetBrains IDEs (WebStorm, IntelliJ) integrate Prettier through Settings → Languages & Frameworks → JavaScript → Prettier. Pre-commit hooks via Husky + lint-staged run Prettier on every staged file before allowing the commit, ensuring no unformatted HTML reaches the repository. CI checks run prettier --check on pull requests to catch formatting drift. None of this matters for one-off snippets pasted from elsewhere, that's exactly what this in-browser tool is for. For long-term project work, set up Prettier; the in-browser tool is the friction-free option for everything else.

Privacy: Why Browser-Only Matters Here

HTML often contains things you don't want a third party to see: internal admin tool templates, unreleased product page markup, A/B-test variants with experiment hypotheses revealed in class names, email templates with personalised content, customer dashboards with PII in placeholders. Server-side formatters upload your HTML to a third-party service where it sits in logs. This tool runs entirely in your browser via JavaScript, verify in DevTools' Network tab while you click Format, or take the page offline (airplane mode) after it loads and the formatter still works. Safe for unreleased product templates, internal admin pages, A/B-test variants or any HTML you wouldn't want copied onto a stranger's hard drive.

Frequently Asked Questions

What is HTML beautification?

Beautification (also called "pretty-printing" or "formatting") reformats HTML source to be more readable, adding proper indentation, line breaks between block elements, consistent attribute formatting. The browser-rendered output is identical because browsers ignore extra whitespace at parse time. The goal is human readability for code review, debugging and editing, not any change to how the page looks.

Will formatting change how my HTML looks in a browser?

For block elements (<div>, <p>, <section>): no. Browsers ignore whitespace between block elements; rendering is identical. For inline elements (<span>, <a>, <strong>): potentially yes, whitespace between inline elements is rendered as a real space. The "preserve inline tags" option (default on) keeps inline elements on the same line as their surrounding text to avoid this. For content inside <pre>, <textarea>, <script> or <style>, the formatter should leave whitespace alone, those elements have whitespace-significant content.

What are inline tags?

Inline elements flow within text rather than creating block breaks. The common ones: <span>, <a>, <strong>, <em>, <code>, <b>, <i>, <u>, <mark>, <sub>, <sup>, <small>, <abbr>. The "preserve inline tags" option keeps these on the same line as their surrounding text, preventing the whitespace bug where breaking a line adds a visible space between words. Block elements (<div>, <p>, <section>) are always free to be reformatted because the whitespace around them isn't rendered.

2 spaces, 4 spaces, or tabs?

2 spaces is the modern web default, used by GitHub, Google HTML/CSS Style Guide, Prettier, the WHATWG style examples and most npm packages. 4 spaces persists in older Java / Microsoft / PHP traditions. Tabs are favoured by the Linux kernel and some Go projects. The argument is older than most readers and unwinnable; the practical answer is to match what your project already uses (or the team's prevailing convention) and have a formatter enforce it. For a one-off snippet without a project context, 2 spaces is the safest default in 2026.

Should I use this if I already use Prettier?

Probably not, your editor's Prettier integration is doing this on save, with full HTML AST awareness and the protected-content handling production formatters require. This tool is for the cases your build pipeline doesn't cover: HTML pasted from a browser inspector, snippets from email or chat, template engine output you want to inspect, one-off formatting outside any project context. For long-term project work, set up Prettier locally; for friction-free one-off work, this tool is the right shape.

Are my HTML files uploaded?

No. Formatting runs entirely in your browser via JavaScript. The HTML you paste never crosses the network, verify in DevTools' Network tab while you click Format, or take the page offline (airplane mode) after it loads and the tool still works. Safe for unreleased product templates, internal admin pages, A/B-test variants, email templates with personalised content, or any HTML you wouldn't want copied onto a stranger's hard drive.

Related Tools