HTML Formatter & Minifier

HTML is one of those formats that looks deceptively simple — angle brackets, attributes, nested tags — and stays simple right up until the moment you have to read 50KB of it written by a templating engine that did not bother to indent. Auto-generated HTML, especially the kind that comes out of CMSs, server-side template renderers, page builders, and email clients, is often a single dense block: opening and closing tags jammed together on one line, attributes wrapped without breaks, scripts and styles stuffed between adjacent tags with no whitespace separator. The markup is correct — browsers parse it fine — but it is unreadable, ungrep-able, and impossible to review for accessibility or structural issues. The formatter's job is to take that block and turn it into something humans can scan: indented children, one logical element per line for the structural tags, attributes wrapped sensibly when they are long, and the protected content blocks (<pre>, <textarea>, <script>, <style>) left exactly as authored because their internal whitespace is significant.

The formatter implementation here uses js-beautify under the hood, which is the same library that powers most modern editor 'beautify' commands and online beautifiers. js-beautify does the heavy lifting of walking the markup tree, deciding which tags deserve their own line and which inline tags should stay on the line with their parent, and producing output that matches the conventions developers expect from a well-formatted HTML file. The configuration knobs we expose — indent size (2 or 4 spaces, or tabs), wrap width (40, 80, 120, or none), and protected tags — cover the cases that matter for everyday work without exposing the dozens of micro-options js-beautify supports for niche use cases. The defaults (2 spaces, 80-column wrap) match the most common style guides; pick the alternates if your team's conventions differ.

Minification is the opposite operation and equally common in the wild. Production HTML pipelines compress markup before serving it: every kilobyte saved is a kilobyte less to download, parse, and store in caches. The savings are not huge in absolute terms — HTML compression typically saves 10-20% of the byte count for unminified markup — but they compound on a high-traffic page where the markup is rendered millions of times per day, and they pair multiplicatively with gzip/brotli compression at the transport layer. The minifier here strips comments outside protected blocks (so HTML comments like <!-- TODO: --> disappear, but JSDoc-style comments inside <script> blocks survive), collapses runs of whitespace to a single space (or zero where the surrounding tags are block-level and the whitespace was insignificant), and reports the savings as a byte count and a percentage so you can see what you bought.

Protected blocks are the part of HTML formatting that catches most naive implementations off guard. The content inside <pre>, <textarea>, <script>, and <style> is whitespace-significant: a <pre> block uses its internal whitespace to render code with the right indentation, a <textarea>'s default value is the literal text between its tags, and JavaScript inside a <script> block obviously cares about line breaks and indentation. A formatter that does not protect those blocks will happily collapse the whitespace inside them and break the page. The implementation here splits the input on a regex that matches the open and close of each protected tag, processes the non-protected segments through the formatter or minifier, and concatenates the protected content back in verbatim. This is also why the byte savings of the minifier vary so much across documents: a page that is mostly markup with little script or style sees big savings, while a page that is half embedded script sees small savings because most of the bytes are protected from collapsing.

Common cases where the formatter earns its keep. First, debugging a rendering issue: minified HTML from production is impossible to step through, but pasted into the formatter it becomes navigable, and the line numbers line up with what your editor would show if you had the source. Second, comparing two versions of a page: format both, then diff line-by-line — without formatting, the diff is useless because the whole page is on one line. Third, reviewing accessibility or structural issues: the indentation reveals the heading hierarchy, list nesting, and ARIA structure at a glance. Fourth, importing legacy markup into a modern documentation tool that wants clean source: format first, then paste. Fifth, teaching students what good HTML looks like — the formatter's output is a useful baseline.

Common cases where the minifier earns its keep are predictable from the production deployment angle. Static-site generators and frameworks (Next.js, Astro, Eleventy, Hugo) increasingly minify their HTML output by default, but if your site is hand-built or your pipeline does not, the minifier here is a one-step optimization that produces a measurable win. Email rendering is another case: HTML emails are often size-budgeted because email clients have envelope size limits, and minification buys a few percent of headroom. CMS exports often produce verbose HTML that benefits from a one-shot minify before being committed to a repository. The minifier output is byte-equivalent semantically — same DOM tree, same rendered result — just smaller.

Edge cases worth knowing. Inline JavaScript with embedded HTML strings (a script that does element.innerHTML = '<div class=...'>') is preserved as-is because the script block is protected. Conditional comments (<!--[if IE]>...<![endif]-->) are preserved by the formatter and stripped by the minifier — most of those targets are now obsolete (IE11 has been EOL since 2022), but if you support a niche audience that still cares about them, keep an eye on what the minifier does to them. SVG inline in HTML is formatted with structure-aware indentation; the formatter does not run a SVG-specific optimizer (use SVGO for that), but the whitespace handling is correct for the markup-level concerns. Custom elements (web components) are formatted like any other tag — the formatter does not know their semantic special-casing, but the structural indentation works regardless.

Privacy is the same model as the rest of Omnvert's tools: the entire formatter and minifier run in your browser. The HTML you paste is never uploaded, never logged, never seen by any server. This matters when the markup contains internal company URLs, customer data baked into the page, or pre-release content. You can verify by opening the browser network tab during formatting — there are no outbound requests beyond the static page assets that loaded the tool. For comparison, many online HTML beautifiers upload the input to a server for processing, which is often forbidden by corporate security policies. The browser-only approach makes this tool usable in environments where those alternatives are not.

The tool pairs naturally with adjacent utilities. Once you have formatted HTML, you can paste it into the Markdown ↔ HTML Converter to produce a Markdown version for documentation. The JSON Viewer is useful when the HTML embeds JSON-LD structured data that you want to inspect; the Schema.org JSON-LD Builder is the right tool for generating that JSON-LD in the first place. The Regex Tester is useful for the bulk-edit workflow where the formatted HTML reveals a pattern you want to substitute everywhere. For developers building on top of the formatted output, the User Agent Parser helps when the HTML output should vary by client, and the Open Graph & Twitter Card Preview verifies that the head metadata is correct.

Performance scales linearly with input size and is essentially instant for typical pages. A 100KB HTML file formats in under 50ms; a 1MB file takes a couple of hundred milliseconds. The formatter and minifier run synchronously, so there is no spinner or progress indicator — the result appears as soon as you click the button. For genuinely huge HTML files (rare in normal work, but possible for archived single-page-app dumps or scraped content), the browser tab will struggle past about 5MB of input; for those cases, command-line tools like html-tidy or prettier are faster and you should use those. The 95th percentile of real HTML files in everyday work fits comfortably within the browser implementation's range.

A workflow tip worth highlighting: format the input first, then minify. Formatting normalizes the whitespace and produces clean indentation; minifying that clean output is more deterministic than minifying directly from a messy source, because the formatter has already resolved the ambiguous whitespace decisions. The minifier is also more aggressive when fed clean input because it has fewer surprises to be conservative about. The byte-savings number is most accurate when measured between formatted-and-then-minified vs original-source — if you minify from messy input directly, the savings number can be misleading because part of the 'savings' was just resolving redundant whitespace that a formatter would have collapsed too.

One last tip about wrapping. The wrap-width setting affects only attribute wrapping; the structural indentation is independent. A wrap of 80 means: when a tag's open form (with all its attributes) exceeds 80 columns, wrap the attributes onto their own lines. A wrap of 'none' means: never wrap, even if the tag stretches to 200 columns. Most editors handle long lines fine, so 'none' is a defensible choice if your team prefers compact source; 80 is the conservative default that keeps everything within a reading-friendly column count. Pick what matches your editor settings and stick with it across files.