When the HTML formatter does not format a snippet, first identify whether it showed an explicit error or returned the input unchanged with a preservation notice. Those outcomes protect different kinds of content; neither one proves that the HTML is valid, safe, or ready to ship.
Identify the outcome before changing the snippet
An error and an unchanged result are separate diagnostic signals. Record the exact input in a scratch copy, the message shown by the page, and whether a formatted result appeared before removing anything.
Consider an email component that combines a compact card, an embedded style block, and a preformatted fallback. The card alone may be simple enough to indent. The style block causes the current formatter to reject the entire pasted input, while the preformatted block causes it to preserve the entire input unchanged. Treating both outcomes as “the formatter is broken” hides the useful distinction.
Start with these questions:
- Did the page display an error about
scriptorstyle? - Did it display a preservation note and return exactly the text you pasted?
- Does the snippet contain
pre,textarea, template delimiters, or mixed inline text? - Is the apparent HTML actually a framework template, email language, or server-side view?
- Can you reproduce the outcome with a smaller, non-sensitive copy?
Do not edit the only copy while answering them. A formatting experiment should never become an accidental source-file rewrite.
An explicit script or style error is intentional
The current HTML Formatter for pasted snippets rejects input containing opening or closing script or style tags. It does not try to parse the JavaScript or CSS inside those elements because braces, comparison signs, strings, and template expressions can be mistaken for HTML structure by a lightweight formatter.
If the review concerns only the surrounding markup, duplicate the snippet and remove the entire script or style block from that temporary copy. Leave a plain note in your review checklist saying which block was excluded. Format the remaining container, then review the excluded JavaScript or CSS with a formatter designed for that language.
If the block is essential to the question, stop using this formatter for the combined snippet. Splitting a real component merely to make an error disappear can conceal dependencies between an element, its class names, and its behavior. A successful result would still not test the script, execute the page, or show whether the selector matches the intended element.
Pre, textarea, and mixed content may be preserved unchanged
An unchanged result can be the correct protective behavior. The component deliberately preserves any pasted input containing pre or textarea, because whitespace and line breaks inside those elements may be user-visible data rather than disposable indentation.
Other complex input can also be returned unchanged. A paragraph such as <p>Hello <strong>reviewer</strong></p> mixes a text node with a nested inline element; the current conservative tokenizer may decline to rearrange it. Text with unsupported angle brackets or content it cannot separate safely can reach the same preservation path.
Preservation is not validation. An unbalanced tag can sometimes still be tokenized and indented, while malformed or template-heavy text may remain unchanged. The formatter has no standards validator, DOM repair report, or framework parser, so “it changed” and “it did not change” are both insufficient answers to “is this correct HTML?”
Reduce the copy to the smallest useful review case
The fastest diagnosis is a controlled reduction, not random deletion. Make a separate scratch copy, replace private URLs and customer content with harmless fixtures, and keep the original nearby as the comparison baseline.
Begin with one plain container, such as <article><h2>Release note</h2><p>Ready for review</p></article>. If that formats, add one original child at a time in its original order. When the outcome changes, the last addition identifies a boundary worth examining.
Use the result to choose the next tool:
- A
scriptorstyleblock belongs in a language-aware formatter and project test. - A
preortextareablock should keep its significant whitespace unless the application specification says otherwise. - Mixed inline content needs a formatter that understands the document model you are using.
- Template expressions need the formatter for that template or framework.
- Suspected malformed markup needs a standards validator, not repeated beautification attempts.
This method also prevents a misleading success. If a reduced fixture formats but the real component does not, report that exact scope instead of saying the component was formatted.
Compare the output without mistaking whitespace for correctness
After a snippet formats, compare it with the preserved baseline. The browser text diff tool can show line, word, or character changes in pasted text, but it does not understand HTML semantics.
Line mode will emphasize nearly every indentation change, so inspect tag names, attribute names and values, text, comments, and element order deliberately. Character mode is useful for a suspicious URL, aria-* attribute, data attribute, or punctuation change, but it can be expensive for a large document. The diff implementation builds a comparison grid and may stall on long character-level input; reduce the case or use a dedicated code diff for large files.
The formatter creates a separate text result. It does not open, save, overwrite, or edit an HTML file. The diff likewise compares the two text fields without reading a repository. Any decision to apply the output belongs in version control, where the project can show the exact patch and run its normal checks.
Validate and render after the formatter step
A useful final check has at least three layers: text comparison, standards or framework validation, and controlled rendering. Skipping the last two turns readable indentation into false confidence.
For plain HTML, run an appropriate validator and inspect the component on a test page at the relevant viewport sizes. For an email template, use the team's email preview workflow. For a server template or UI component, run its compiler, linter, tests, and local review process. Check keyboard access and accessible names when the snippet contains controls or meaningful images.
The browser formatter does not load stylesheets, execute scripts, resolve imports, test links, evaluate template variables, detect duplicate IDs, or compare screenshots. It also cannot decide whether changing whitespace is safe inside every custom element. Those are not hidden features; they are explicit reasons to keep the formatter step small.
Before handing off the result, confirm that the original is still available, sensitive values were not pasted, excluded blocks were documented, meaningful text and attributes match, and the appropriate validator or project test passed. If any check is missing, hand off the original plus the unresolved question rather than a supposedly cleaned file.
Frequently asked questions
Why does a script or style tag reject the whole snippet?
The current formatter refuses those blocks because their contents have language rules that a lightweight HTML tokenizer should not guess. Review the surrounding copy separately or use a JavaScript- or CSS-aware formatter for the complete block.
Why does pre or textarea come back unchanged?
Whitespace and line breaks can be part of the value displayed by pre or entered through textarea. Preserving the entire pasted input avoids a cosmetic rewrite that could alter meaningful content.
Does an unchanged result mean my HTML is valid?
No. It only means the formatter chose not to rearrange that input. A standards validator or the relevant framework compiler must answer structural questions, and a controlled preview must answer rendering questions.
Does a formatted result mean malformed tags were repaired?
No. The tool does not produce a repair log or validate the document model. Some malformed input may still be indented into a plausible-looking shape, so compare the source and run a validator before applying anything.
Can ToolboxHub edit the source HTML file for me?
No. The formatter only transforms text pasted into the page and presents a separate result. It does not open or write a project file, and the related diff tool only compares text placed in its two fields.