{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ referenceModeLabel }} {{ resultsReady ? `${computation.values.passes_used} passes` : 'Waiting' }} {{ reviewLabel }}

{{ primaryCopyAnnouncement }}

HTML character reference inputs
Paste one snippet or load one TXT, HTML, or HTM file. Processing stays in this browser.
{{ sourceMeta }}
{{ sourceStatus || 'Drop one HTML or TXT file onto the textarea.' }}
Use strict review when malformed or incomplete source references must remain visible.
One pass is literal; two handles most double-escaped CMS, email, and template text.
passes
The neutral default preserves the exact decoded Unicode sequence.
Off by default so the decoded snippet retains its original outer spacing.
{{ trimOutputEnabled ? 'Trim on' : 'Preserve spacing' }}

{{ artifactAnnouncement }}

{{ computation.values.decoded_text }}
{{ tableExportAnnouncement }}
#ReferenceDecodedKindPassStatusCopy
{{ row.sequence }}{{ row.reference }}{{ row.decoded }}{{ row.kind }}{{ row.pass }}{{ row.status }}
Safety review
{{ row.check }}{{ row.status }}
{{ row.detail }}
{{ chartExportAnnouncement }}

An ampersand-led token may stand for one character or hide another escape sequence. In &lt;, one decode reveals a less-than sign. In &amp;lt;, the first decode reveals &lt; and a second is needed to reveal <. That difference matters when text has crossed several templates, feeds, email systems, or content-management fields.

HTML calls these tokens character references. Named references use labels from the HTML table, while numeric references identify a Unicode code point in decimal or hexadecimal. They let markup-significant characters and symbols travel as text, but malformed or unfamiliar spellings may remain unresolved.

Examples of HTML character-reference forms
FormExampleDecoded character
Named&copy;©
Decimal numeric&#169;©
Hex numeric&#x1F680;🚀
Nested&amp;lt;< after two passes

A semicolon is the clearest end marker. Conforming HTML references include it, although HTML parsing retains a limited set of semicolonless names for legacy compatibility. A tolerant decode may accept one of those old forms; a strict source review can leave it visible so the missing delimiter is fixed instead of silently accepted.

Unicode normalization is separate from reference decoding. NFC composes canonically equivalent sequences where possible. NFKC also applies compatibility mappings, which can fold distinctions such as presentation variants. Leaving normalization off best preserves the exact decoded sequence.

Unescaping reveals text; it does not make that text safe HTML. A decoded tag, event-handler attribute, or javascript: fragment remains untrusted input. Keep the result as text until the destination applies a context-appropriate sanitizer and security policy.

How to Use This Tool:

Start with the fewest transformations that reveal the intended text, then inspect what remained or became visible.

  1. Paste text into Escaped HTML, drop plain text, or load one TXT, HTML, or HTM file smaller than 512 KiB. Only the first dropped file is read.
  2. Choose HTML5 tolerant for legacy-compatible decoding or Strict semicolons when every reference must end in ;.
  3. Set Decode passes from 1 to 6. Use one for ordinary references and two only when an earlier pass exposes another encoded token.
  4. Leave Unicode normalization at No change unless comparison requires NFC or NFKC. Enable trimming only when leading and trailing whitespace are intentionally disposable.
  5. Read Reference ledger and Safety review before copying the decoded text. Unresolved references or script-shaped output require inspection, not more passes by default.

Interpreting Results:

The headline count measures decoded reference occurrences across all passes. A nested token may appear in more than one pass, so References seen is an audit-event count rather than the number of unique tokens in the original text.

Unresolved references stayed unchanged because they were unsupported, ambiguous without a semicolon, or rejected by strict mode. Check the ledger's pass, kind, and source spelling before deciding whether the token is a mistake or literal text.

Markup signals and Script signals are pattern warnings. Zero signals is not proof that the output is safe to render, and a positive signal is not proof of an exploit. Use them to decide where a real parser, sanitizer, or security review is needed.

Technical Details:

Decoding scans ampersand-led named, decimal, and hexadecimal candidates. Each requested pass replaces recognized candidates, records every match in order, and stops early when a pass decodes nothing. Normalization and outer-whitespace trimming happen after the reference passes.

Transformation Core

The stages are deterministic for the same source and settings.

HTML unescape transformation stages
StageTransformationEvidence retained
1. PrepareOptionally remove outer whitespaceInput character count
2. ScanFind reference-shaped tokens in source orderReference spelling and pass
3. DecodeMap recognized names or numeric code pointsDecoded value, kind, and status
4. RepeatRun up to the selected pass count; stop after a no-change passSeen, decoded, and unresolved counts per pass
5. NormalizeApply no change, NFC, or NFKC, then optional final trimChanged-policy cue
6. ReviewCount tag-shaped and common script-shaped patternsSafety rows and profile counts

Rule Core

Reference policy decides whether a token changes or remains available for review.

Exact HTML reference decoding rules
CandidateHTML5 tolerantStrict semicolons
Known named reference with ;DecodeDecode
Known legacy name without ;DecodeLeave unchanged
Other named reference without ;Leave unchanged as ambiguousLeave unchanged
Decimal or hexadecimal numeric reference without ;DecodeLeave unchanged
Unknown nameLeave unchangedLeave unchanged

Numeric values are interpreted as Unicode code points. Selected values from 128 to 159 use HTML's Windows-1252 compatibility mapping. Zero, values above U+10FFFF, and UTF-16 surrogate code points become the replacement character U+FFFD. Named lookups are case-sensitive because the HTML table contains distinct names.

NFC and NFKC use Unicode normalization after all reference replacement. Trimming, when enabled, applies before the first pass and again after normalization. Character counts use Unicode code points rather than UTF-16 code units, and source text is limited to 20,000 characters.

The safety scan counts tag-shaped segments and common patterns for script, iframe, object, embed, event-handler attributes, and javascript:. It does not parse the result into a document tree, execute it, or remove anything.

Limitations, Privacy, and Safety Notes:

  • Text and accepted files are decoded in the browser and are not uploaded for this operation.
  • The current source and settings are mirrored into the page address. Do not paste secrets, and do not share or save a URL that contains confidential source text.
  • A 512 KiB file can still exceed the 20,000-character source limit after loading and will then be rejected for decoding.
  • Decoding is not sanitization, validation, rendering, or proof of safety. Keep untrusted output inert until the destination's security controls accept it.

References: