Malformed HTML is everywhere.
Loading HTML Formatter…
Repairs missing or mismatched closing tags
Re-emits HTML using the standards-compliant tree
Preserves text content exactly
Browser-only with no upload of broken markup
Drop the HTML Formatter into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.
Embed code
<iframe
src="https://www.fixtools.io/html/html-formatter?embed=1"
width="100%"
height="780"
frameborder="0"
style="border:0;border-radius:16px;max-width:900px;"
title="HTML Formatter by FixTools"
loading="lazy"
allow="clipboard-write"
></iframe>Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.
Malformed HTML is the rule rather than the exception in real-world codebases. The HTML5 specification defines extensive error recovery rules precisely because the web cannot afford to break on every minor source error, and browsers implement these rules to render even badly broken markup into something visible. The recovery rules turn missing closing tags into inferred closures at the appropriate point, treat unquoted attribute values as quoted with implicit boundaries, and absorb stray characters as text content where they appear. Two browsers given the same malformed input usually produce the same DOM tree because they implement the same recovery rules, even though the rules are complex and counterintuitive in edge cases.
FixTools fixes malformed HTML by parsing the input with the same recovery rules a browser applies, which produces a DOM tree that matches what the browser would render. The tool then re-emits the tree as well-formed HTML with explicit closing tags, properly quoted attribute values, and consistent indentation. The output has the same rendered behaviour as the input, because both produce the same DOM tree, but the source is now valid HTML that passes specification-compliance checks. This is the most reliable way to clean up malformed HTML because it relies on the same tolerant parser the browser uses, rather than on heuristics that might guess incorrectly at the developer intent.
The fix is one-directional in the sense that information lost in malformed source cannot be recovered. If the original developer intended a different structure than what the recovery rules produced, the fixed output reflects the recovery rules rather than the original intent. The fixed output is what the browser actually renders, which is usually what you want; if the rendered output is wrong, the fix is to edit the source explicitly rather than to assume the parser will magically infer the correct intent. The tool produces a deterministic, browser-compatible output, and the developer remains responsible for verifying that this matches their actual design goal.
Common patterns the fix handles correctly include p elements that contain block-level children, which the parser closes implicitly at the start of the child; li elements that lack closing tags, which are closed at the start of the next li or the parent list closure; img elements with self-closing slashes, which are emitted in their canonical form; and attribute values with unusual characters such as spaces or quotation marks, which are emitted with proper quoting to preserve the value exactly. Each of these patterns is well-defined in the HTML5 specification, so the fix is predictable and reproducible regardless of which input you start from.
Paste your malformed HTML and click Format. The output shows a well-formed, properly indented version produced by the standards-compliant parser.
Step-by-step guide to fix malformed html:
Paste your malformed HTML
Paste any HTML, including HTML with missing closing tags, mismatched nesting, unquoted attributes, or stray characters, into the input panel.
Click Format
Click Format. The tolerant HTML5 parser builds the same DOM tree a browser would construct from your input, then re-emits it as well-formed markup with proper indentation.
Verify the rendered output
Compare the rendered output of your original and fixed HTML to confirm the fix matches your design intent. If the rendered output differs, the difference is in your source rather than introduced by the fix.
Validate the fixed output
Run the fixed output through the FixTools HTML validator to confirm it is now spec-compliant. The validator should report no structural errors on the fixed output.
Common situations where this approach makes a real difference:
Fixing CMS-exported HTML for a static site rebuild
A team rebuilding a site from a CMS export runs every page through the fixer to produce a well-formed baseline for the static site generator. The fix removes a category of subtle rendering issues that the CMS had worked around with implicit recovery, and the rebuilt site validates cleanly across all pages from the first deploy.
Cleaning up email HTML after a merge tag failure
A marketer fixes the malformed HTML produced by a merge tag failure that left a partial tag in the body. The fixer infers the correct closure and emits a valid version that renders correctly across all email clients, which the manual approach of guessing the right closure would not reliably produce.
Fixing HTML extracted from a PDF export
A developer fixes the HTML produced by a PDF-to-HTML conversion tool that introduces dozens of unclosed elements per page. The fixed output is valid HTML that can be styled with normal CSS, while the original output produced unpredictable rendering depending on the browser.
Fixing user-generated HTML in a forum post
A platform team fixes the malformed HTML allowed through a permissive sanitiser to produce a well-formed version for display. The fix prevents the layout breakage that would otherwise occur when malformed user posts leak into surrounding page chrome through implicit element closure.
Use this when you have HTML that is rendering incorrectly, failing validation, or producing parser warnings, and you want a clean, well-formed version as a baseline for further work.
Get better results with these expert suggestions:
Run the fixer on every legacy file you inherit
When you inherit a legacy HTML codebase, run the fixer on every file as a one-time cleanup pass. The fix produces a well-formed baseline that any subsequent work can rely on, which prevents the slow accumulation of structural issues that comes from editing already-malformed source. The cleanup pass is a small one-time investment compared to the recurring cost of working around malformed source in every future change.
Diff the original and fixed output to find structural issues
After running the fix, diff the original and fixed output to see exactly what the recovery rules changed. Each diff hunk highlights a place where the original source was malformed, which gives you a precise list of issues to investigate or document. Many of these issues will turn out to be intentional patterns that the team has worked around for years, which become candidates for explicit fixes once the malformations are visible.
Use the fix to debug rendering surprises
When a page renders surprisingly, run the source through the fixer and look at the structural changes. The fix often reveals that a missing closing tag is causing implicit closure at a different point than the developer intended, which produces unexpected nesting that explains the rendering surprise. The fix is faster than manually tracing through the HTML5 recovery rules to understand what the parser actually did with the malformed source.
Format and validate as a pair
Always run the fixer and a validator together. The fixer produces well-formed output that the validator can evaluate against the full specification, which catches issues that go beyond malformation: deprecated elements, missing required attributes, accessibility issues, and so on. Using both tools in sequence gives you a comprehensive quality check that is faster and more thorough than either tool alone.
Verify the rendered output after fixing
Compare the rendered output of your original and fixed HTML to confirm the fix matches your intent. If the rendered output differs, the issue is in your design rather than in the fix.
Run the fixed output through a validator
After fixing, run the output through an HTML validator to confirm it is now spec-compliant. The validator should report no errors on the fixed output.
Use the fix as a starting point, not a final answer
The fix produces a baseline well-formed version. Treat it as the starting point for further structural improvements rather than as a complete solution to the original issue.
More use-case guides for the same tool:
Open the full HTML Formatter — free, no account needed, works on any device.
Open HTML Formatter →Free · No account needed · Works on any device