HTML Formatter_
Paste minified or tangled HTML and get it back indented and readable — with the indent size, tab or space, wrap width and attribute wrapping under your control, and the CSS and JavaScript inside <style> and <script> formatted too rather than left as one long line.
Formatting HTML is not cosmetic: whitespace between inline elements is rendered, so a formatter that breaks a line in the wrong place changes what your page looks like. This one leaves <pre> and <textarea> byte-identical, never splits an inline run, and runs entirely in this tab — the markup you paste is never uploaded.
Indentation you can see, whitespace you cannot
Why reformatting markup is riskier than reformatting code
Reindent a JavaScript file and it behaves identically: the language ignores whitespace between tokens. HTML does not. A run of whitespace between two inline elements collapses to one rendered space — not to nothing. So <b>a</b> <i>b</i> displays “a b”, and a formatter that puts each element on its own line has not changed the spacing, while one that joins them has deleted a space the reader could see. The safe move is to add line breaks only where whitespace was already being discarded — between block-level elements.
The elements that must never be touched
Inside <pre> and <textarea> every space and newline is content: displayed exactly as written, so re-indenting changes what the user reads or submits. A code sample loses its alignment; a textarea gains leading spaces that end up in the form data. The same applies to <script> bodies that are not JavaScript — a text/template block holds markup for a client-side renderer, and reflowing it changes what that renderer outputs. All of these come through unchanged here, which is worth checking on any tool before trusting it with a real document.
What the options actually do
Indent size and character are the obvious pair, and matching what your repository already uses matters more than which you pick — a formatter that disagrees with your editor turns every save into a diff. Wrap width is the one people miss: at Never, a tag with a dozen attributes stays on one 400-character line, unreadable, and produces a diff that highlights the whole line for a one-attribute change. Attribute wrapping is the finer control on the same problem: force-aligned puts each attribute on its own line, which is what component-heavy markup wants. Preserve newlines keeps the blank lines you put in deliberately.
Formatting is not validation
A document can be beautifully indented and still broken. Formatters are built to be forgiving — they lay out markup with an unclosed <div> or a </i> that closes nothing, because refusing would make them useless on the input people actually have. Tidy output is not evidence that anything was checked. This page names the structural problems it noticed and stops there: conformance checking is the W3C validator's job, and implying otherwise would be worse than saying nothing.
How to use
- 01Paste your markup, or Upload a file — read in this tab, never sent anywhere. Sample loads the worked fragment from the table below.
- 02Set indent size and character to match your repository. Everything reformats as you type, so each option shows its effect immediately.
- 03Set a wrap width if long tags are the problem, or switch attribute wrapping to force-aligned for one attribute per line.
- 04Copy or Download the result. Minify does the opposite — whitespace stripped everywhere it is not rendered, and nowhere it is.
Four ways this gets used
A minified page you have to read
View-source on a built page is one line 200 KB long. Formatting is the only way to find the element you want.
one very long line
an indented tree you can scroll
A diff that is unreadable
Two files differ only in formatting, so every line shows as changed. Format both the same way and the real change appears.
both files, same options
a diff with three changed lines, not three hundred
An email template full of inline styles
Table-based email markup carries enormous style attributes; force-aligned wrapping makes each reviewable.
force-aligned
one attribute per line, aligned
Markup you cannot paste elsewhere
An invoice template or a rendered page with a customer's name and address. Several well-known formatters process on their server.
processed in the tab
nothing transmitted, enforced by the CSP
Every option, on one worked fragment
| Option | Setting | What it does to the fragment |
|---|---|---|
| — | The input | <div class="a"><p>hi <b>you</b></p></div> |
| Indent size | 2 (default) | <div class="a"> ⏎ <p>hi <b>you</b></p> ⏎ </div> |
| Indent size | 4 | The same, with four spaces before <p> |
| Indent with | Tabs | The same, with one tab before <p> — no spaces anywhere |
| Wrap lines at | Never (default) | A tag with twelve attributes stays on one line |
| Wrap lines at | 80 | That tag breaks across lines once it passes 80 characters |
| Attribute wrapping | Auto (default) | Attributes stay on the tag line until the wrap width breaks them |
| Attribute wrapping | Force-aligned | Every attribute on its own line, aligned under the first |
| Preserve newlines | On (default) | A blank line between two sections survives |
| Preserve newlines | Off | Blank lines are removed; only structural line breaks remain |
| Mode | Minify | <div class="a"><p>hi <b>you</b></p></div> — the space before <b> survives |
Note the last row: minifying removes whitespace between block elements, where it is discarded anyway, and keeps it between inline elements, where the browser renders it.
Where whitespace is content, not layout
| Element / context | What whitespace means there | If a formatter collapses it |
|---|---|---|
<pre> | Displayed literally — spaces, tabs and newlines all render | Code samples lose their alignment; ASCII art breaks |
<textarea> | The field's initial value, character for character | Users submit leading whitespace they never typed |
| Between inline elements | Collapses to one rendered space | Words run together: a b becomes ab |
<script> (JavaScript) | Insignificant, except in template literals | Safe to reformat — this page does, with the JS engine |
<script type="text/template"> | Content for a client-side renderer, not this document | Whatever it renders changes; left untouched here |
<style> | Insignificant | Safe to reformat — this page does, with the CSS engine |
| Between block elements | Discarded by the renderer | Nothing — this is where a formatter is free to indent |
white-space: pre via CSS | Displayed literally, but a formatter cannot know | Layout shifts, and no tool can warn you |
The last row is the honest limit of any HTML formatter: whitespace significance can be set from a stylesheet, which the markup alone does not show.
Tips & best practices
- Match your repository, not your taste. A formatter that disagrees with everyone else's editor turns every save into a needless diff.
- Set a wrap width before reviewing a diff. Unwrapped 400-character lines make a one-attribute change look like a rewrite.
- Format both sides before comparing two files in the diff checker — most "everything changed" diffs are a formatting mismatch.
- Check a
<pre>block after using any formatter for the first time. If its content moved, stop using it for real documents. - Formatting is a review aid, not a build step: ship minified markup and keep the formatted copy for reading.
- Working with XML rather than HTML? Use the XML formatter — the rules differ enough that the wrong one errors on correct documents.
Gotchas — how formatting changes a page
Whitespace between inline elements is rendered
A space between </b> and <i> shows up on screen. Put those elements on separate lines and the break is still one rendered space, so nothing changes — join them and the space is gone and the words run together. This is the one way a formatter can silently alter what your page looks like, and why this tool never breaks a line inside an inline run and never joins them when minifying.
<pre> and <textarea> must come through untouched
Everything inside them is displayed exactly as written. Re-indenting a <pre> shifts every line of a code sample; re-indenting a <textarea> puts whitespace into the value a user submits. Plenty of formatters do exactly this — paste a document with a <pre> block into any new tool and check before trusting it.
Formatting is not validation
Formatters are deliberately forgiving: they lay out markup with an unclosed <div> or a stray </i> rather than refuse. Tidy output is not evidence that anything was checked. This page names the structural problems it noticed and points at the W3C validator for the real answer.
Minified HTML arrives as one enormous line
A built page can be a single line hundreds of kilobytes long. Formatting fixes the structure, but at wrap width Never, tags with long class lists stay unreadable. Set a wrap width or force-aligned wrapping when the input came out of a bundler.
Pasting customer data into a server-side formatter
A rendered invoice, an email template with a real address, a support-ticket export — this markup routinely contains personal data, and several well-known formatters process it on their server. Their privacy pages may promise the data is transient, which is a promise about retention, not transmission. Here it is formatted in this tab: the Content-Security-Policy permits no outbound connections and a test fails if a tool function attempts one.
Technical details
- Engine
js-beautify2.0.3 (MIT), the library beautifier.io runs, loaded on first use rather than in the initial page bundle- Embedded code
<style>bodies through the CSS beautifier, JavaScript<script>bodies through the JS beautifier, at the block's indent level- Left untouched
<pre>and<textarea>content byte-for-byte, non-JavaScript script bodies, conditional comments, entities, and self-closing slashes as written- Options
- Indent 2/4/8, spaces or tabs, wrap at 80/100/120 or never, attribute wrapping auto/preserve/force-aligned, preserve newlines
- Idempotence
- Formatting twice equals formatting once — asserted across every fixture and option combination, so it is safe in a pipeline
- Size limits
- Up to 8 MB. Above 2 MB the pane shows the first 2 MB with a notice; Copy and Download still give the whole document
- Safety
- Text in, text out. Pasted markup is never assigned to innerHTML, parsed into the document, or evaluated
- Network
- None from tool code. A test sweep calls every function this page uses with
fetchandXMLHttpRequestreplaced by stubs that throw, so a stray request fails the build instead of shipping. Disconnect from the network and the page still works.
Frequently asked questions
How do I format HTML online?
Paste it above and it reformats as you type. Set the indent size and character to match your repository, add a wrap width if long tags are the problem, then copy the result. Nothing is uploaded — it runs in this tab.
Does formatting change how my page renders?
It should not, and here it does not, but it can in general. Whitespace between inline elements renders as a space, so a formatter that joins or splits them wrongly changes the display. This one never breaks a line inside an inline run and never joins two inline elements when minifying.
Will it reformat the CSS and JavaScript inside my page?
Yes — <style> bodies go through the CSS beautifier and JavaScript <script> bodies through the JS beautifier, indented to match the block. Script blocks that are not JavaScript, such as text/template, are left exactly as written.
Does it validate my HTML?
No, and it says so. It names structural problems it noticed while formatting — an unclosed tag, a closing tag that matches nothing — but formatting is forgiving by design and tidy output proves nothing. For conformance, use the W3C validator.
What happens to my <pre> and <textarea> content?
Nothing. It comes through byte-identical. Everything inside those elements is displayed exactly as written, so re-indenting them would change what your page shows and what your forms submit.
Can I use it on XML?
Use the XML formatter instead. HTML and XML look similar and are not: void elements never close, attributes may be unquoted, tag names are case-insensitive, some end tags are optional. An XML parser reports errors on correct HTML.
Is there an extension that does this in my editor?
Yes, and for day-to-day work it is the better answer — Prettier and the Beautify extension format on save in VS Code and most other editors. A web page is for markup that is not in your editor: something you were sent, something from view-source, something you cannot paste into a server-side tool.