Formatting is the part of a code workflow that nobody notices until it is missing: a wall of HTML reads like one long word, and the same wall becomes a tree the moment the indentation is right. A formatter does not change what your markup means, it changes what it costs you to look at, and that difference is where most debugging time actually goes. The HTML Formatter runs entirely in your browser: you paste the markup, pick a mode, and the output appears in the pane next to it. Nothing is uploaded and nothing leaves the tab, which matters when the page you are cleaning up contains API keys, internal hostnames, or customer data you would rather not paste into a third-party service.
The tool works in two directions, and they answer different questions. Format mode asks, what does this structure look like when the whitespace is honest? Minify mode asks, how small can this file get without a single behavioral change? The rest of this guide covers how both passes work, what happens to a realistic 458-character page in each mode, which parts of the document the minifier refuses to touch and which parts it deletes, how the indentation settings and the inline-element list shape the formatted output, and where this tool sits relative to the other format-specific tools in the set.
How an HTML Formatter Works: two modes, one paste
Both modes read the same input string and write a plain-text result into the output pane; the difference is the transformation applied. Format mode hands the markup to the js-beautify HTML engine with a fixed option set: indentation of two or four spaces, no line wrapping, no trailing newline, no indentation inside inline elements, and a list of elements whose contents are never split across lines. Minify mode runs a purpose-built pipeline instead: it first lifts every script, textarea, and pre block out of the document and holds them aside, then strips HTML comments, collapses every run of whitespace to a single space, removes the spaces around tag junctions, and finally puts the protected blocks back byte for byte.
That ordering is the whole design. Whitespace collapsing is safe for markup and even for the CSS inside a style tag, because in both of those languages a run of spaces and newlines means the same as one space. It is not safe for the inside of a pre tag, where the whitespace is the content, and it is not safe for script, where the minifier would happily glue statements together. Extract-then-restore is what lets the tool make aggressive passes over the rest of the document while those three regions come out exactly as they went in, newlines and all.
The Standard Case: a 458-character Page Becomes One 281-character Line
Take a hand-written page: a doctype, a head with a charset, a title, a small style block, and a body holding a card with a heading, a paragraph, and a button. Written the way people actually write it, with the indentation you would type and a leftover draft comment, it runs 458 characters across 28 lines. Run format mode on it and the page comes back at 390 characters over 27 lines: the over-indented title and heading collapse onto their own lines, the structure is re-anchored to a consistent two-space rhythm, and the draft comment is left in place. If your project standard is four spaces, the same pass returns a document at the same line count with wider indentation.
Run minify mode on the same 458-character page and the result is 281 characters on a single line, a reduction of 38.6 percent. The draft comment is gone, the indentation is gone, the spaces between tags are gone, and what remains is the same document: same elements, same attributes, same text, same CSS. If you want the before and after figures next to each other without doing the arithmetic by hand, the Character Counter & Analyzer reads the length of either pane and makes the saving visible as a number you can quote in a pull request.
What Minify Protects and What It Strips
Three block types are lifted out of the document before any collapsing happens: script, textarea, and pre. A page that contains a script with two assignments, each on its own line, comes back from minify with both newlines intact, because the whole block, opening tag through closing tag, travels to the output untouched. A pre block that depends on double spaces and line breaks to render as a code listing keeps every one of them. The protection is byte-for-byte, not line-for-line, so it also holds for whitespace that looks accidental but is load-bearing, such as the spaces that keep an inline element from merging with its neighbor.
The protection is a boundary, not a destination. The script inside a protected block is safe from the HTML pass, and that is all the HTML pass can promise: real JavaScript minification is a syntax question, where dead statements, redundant parentheses, and safe identifier renames can all be deleted, and the JavaScript Formatter & Minifier does that pass with an engine that parses the code instead of pattern-matching it. The style tag sits on the opposite side of the boundary: its CSS is not protected, so it gets the whitespace treatment, rules intact, spacing shrunk, and the result still valid CSS. Where the stylesheet deserves a deeper pass, the CSS Minifier takes over, with an engine that knows where a space between a selector and a declaration is load-bearing and where it is pure noise.
Everything outside those blocks gets the full treatment, and two details are worth knowing. HTML comments are deleted outright, and the pass runs the comment removal twice, once before the whitespace collapse and once after, because collapsing can move two half-comments together into one that only exists in the collapsed form. And the spaces around tag junctions, the gaps between a closing bracket and the next opening bracket, disappear, so the output is one unbroken line of angle brackets. One quirk to expect: where a protected block sat inside the flow, a single space can remain in its place, because the space was collapsed around a placeholder, not around the real tag. Nothing breaks; the file is still valid, it just is not as tight as the rest of the line.
Format Mode: indentation, wrapping, and the inline element list
The formatter exposes one setting that most users change, and it is the indentation width: two spaces by default, four as an alternative. On the 197-character five-line sample with a comment and a small script, the two-space pass returns 244 characters across 18 lines, and the four-space pass returns the same 18 lines at 278 characters. Same structure, same line count, more horizontal room; the choice is a team convention, not a correctness question. Line wrapping is deliberately disabled, so a long attribute list stays on one line instead of being broken at an arbitrary column, and the output ends exactly where the last tag ends, with no trailing newline added.
The subtler setting is the list of elements treated as inline: a, span, td, th, small, pre, and code. For those tags the engine refuses to break the line between the opening and closing bracket, so a link that wraps a word in the middle of a sentence stays on one line, and a table cell keeps its content from fragmenting across the page. That list is why the formatted output of a prose-heavy page reads the way you would hand-indent it: block elements stack, inline elements flow, and nothing in the middle of a sentence gets a line break bolted into it.
Adjacent Formats: JSON, XML, and Where Each Formatter Sits
HTML is the most forgiving of the markup languages, which is exactly why it gets the most whitespace abuse. A JSON payload, on the other hand, breaks the moment an extra comma or a trailing space sneaks in, so it gets its own tool with a validator that will tell you the line and the reason: the JSON Formatter reads the same kind of pasted blob and returns it pretty-printed or rejected, which is the right companion when the HTML you are cleaning up embeds a configuration object in a script tag. XML is the stricter cousin, where a mismatched bracket is a hard error rather than a browser guess, and the XML Formatter handles that family of documents with the same format-plus-minify pattern.
The point of the split is that each format gets an engine that actually speaks it: an HTML reflow for the document, a CSS-aware engine for the stylesheets, and a JS parser for the scripts. Running the four tools over one page is the same division of labor a build system makes with its toolchain, only without the build: format the document, minify the payloads, and ship the result. The HTML formatter is the piece that keeps the structure human-readable in the middle of it, which is the part a generic minifier gets wrong first, because it optimizes for file size while you are still editing.
Reading the Result Before You Ship It
The output pane is the whole review surface, so it pays to read it the way a reviewer would. In format mode, scan for structure first: do the blocks nest the way you expect, does the list of inline elements keep your prose readable, and is there any element that the two-space rhythm has made harder to follow? The comment that minify deletes is the one place where the two modes disagree about what your file contains, and if that comment was load-bearing for the next person, format mode is the version to keep.
In minify mode the review is shorter and more mechanical. The file should be one line, the tags should be contiguous, and the protected regions should survive: open the output, find the script, and confirm the newlines are still there. If you need the page as plain prose rather than markup, the HTML to Text Converter strips the tags and hands back the reading view, which is the right move when the deliverable is a paste into a document, not a deploy. And when the config that drives the page lives in a YAML file next to the markup, the YAML Formatter gives that file the same treatment. Paste in, pick a mode, read the output, copy it out: the whole loop stays in the tab that has the file, start to finish.