An exported product description or copied message can contain & where you expect an ampersand. HTML entity decoding can turn those references into readable characters. Keep the original, decode a sample once, and decide how the resulting text will be used before processing the rest.
This procedure uses the HTML Encoder and Decoder to clean a literal text field. It does not remove HTML tags or make the result safe to insert as webpage markup.
Check that the input contains character references
HTML character references include named forms such as &, decimal forms such as —, and hexadecimal forms such as —. The two numeric examples represent an em dash. MDN explains these three reference forms and how they represent characters.
Check the underlying text rather than a formatted preview. A browser may already display an encoded value as its decoded character. If the actual field contains an ordinary ampersand, leave it alone. This workflow is for a field containing the literal reference spelling.
Decode one sample and inspect the result
Suppose a fictional menu export contains this text:
Tea & Biscuits — <strong>menu</strong>- Open the HTML Encoder and Decoder and choose Decode entities back to text under Mode.
- Paste the sample into Input and click Convert.
- Read the output and the Entities decoded and Left as written counts.
- Check the decoded text against the intended wording, then click Copy only when it is correct.
The expected output is:
Tea & Biscuits — <strong>menu</strong>The tool decodes six references in this sample. The angle brackets remain visible as literal text; they do not turn the word menu into bold text in the output box. Decoding changes reference spellings into characters. It does not strip the resulting tag-like text.
Review anything left unchanged
The decoder uses a fixed named-reference table plus numeric parsing. It does not support every named reference understood by a full HTML parser. For example, this deliberately invented name stays unchanged and is flagged under Left as written:
Keep &NotARealEntity; hereAn unchanged reference needs investigation; the tool alone cannot tell you whether the source contains a typo or a valid name outside its table. Its matching also expects a terminating semicolon. A zero warning count does not prove that every unusual fragment was recognized, and it is not a security assessment.
Do not keep decoding until every ampersand disappears
One conversion of &lt; produces the literal text <. A second conversion would produce <. That second change may be wrong if the field is documenting the reference itself. Confirm the intended value with the export specification or a known source record before removing another layer.
If a second pass is justified, copy the reviewed output into Input, keep Decode mode selected, and convert again. The separate Use output as input button switches modes, so do not assume it repeats decoding.
Keep decoded text separate from HTML markup
For a plain text destination, paste the result as text and inspect it there. In JavaScript, assigning text to an ordinary paragraph or div through textContent creates text instead of parsing tags. MDN distinguishes textContent from innerHTML; do not transfer decoded export values into innerHTML just to display them.
If a server template must include the value in HTML, use its appropriate output escaping for that exact context. URL, attribute, and script locations have different requirements, as described in OWASP output encoding guidance. Decoding is not HTML sanitization. For displaying literal code in a page, follow the separate guide to showing HTML as text without double escaping.
Check the exported result before replacing the original
Keep a short record of the original field, the decoded result, and any unresolved references. Check punctuation, spaces, and line breaks in the receiving application. For a longer edit, use the text comparison workflow to review changes before replacing the source. Stop when the field contains the intended text, even if an intentional reference remains.