HTML Encoder Decoder
Encode reserved HTML characters, convert non-ASCII text to numeric character references when needed, or decode named and numeric HTML character references in your browser.
Output
Encoded or decoded output will appear here...
What stays local, and what escaping cannot protect
Encoding and decoding happen in the browser without sending the entered value to a conversion API. Escaping characters is still different from sanitizing untrusted HTML, and decoded text should not be inserted into an active page as markup unless that destination is handled safely.
Character references change the spelling, not the character
HTML can write a character directly or represent it with a character reference. & is a named reference, & is decimal, and & is hexadecimal; all three can represent an ampersand in an HTML context where character references are recognized. The syntax and parsing rules come from the WHATWG HTML character-reference rules.
For ordinary modern HTML, readable Unicode is normally preferable to turning every non-ASCII character into a numeric reference. The reserved-character mode focuses on ampersand, angle brackets, quotes, and apostrophes. The ASCII-safe option is mainly for inspecting code points or working with a text pipeline that genuinely requires ASCII-only source.
Literal markup in documentation
Input:
<p title="A & B">Café ☕</p>
Reserved-character output:
<p title="A & B">Café ☕</p>
Numeric references and Unicode
In ASCII-safe mode, é becomes é and 😀 becomes 😀. Supplementary characters are handled by Unicode code point, so an emoji becomes one numeric reference rather than two UTF-16 surrogate references.
Turning Unicode into references does not repair a wrong charset declaration or corrupted bytes. It only changes how the same character is written in HTML source.
C1 controls (U+0080–U+009F) and unpaired UTF-16 surrogates are rejected in ASCII-safe mode. HTML has legacy numeric-reference remapping in the C1 range, while surrogate references become the replacement character, so emitting those references would not preserve the original code unit faithfully.
Escape for the place where the value will be inserted
HTML text, quoted attributes, URLs, JavaScript, and CSS are different output contexts. Escaping literal markup for a paragraph is not a universal security transformation. Frameworks normally apply the right escaping when values are inserted through ordinary text or attribute bindings; bypassing those protections deserves deliberate review.
| Destination | What to keep in mind |
|---|---|
| Visible HTML text | Escape markup-significant characters so literal tags remain text. |
| Quoted attribute | The matching quote and ampersand matter; prefer the framework's normal attribute binding. |
| Untrusted rich HTML | Character escaping alone cannot decide which elements, attributes, or URLs are safe. |
| JavaScript, CSS, or URL data | Apply the rules for that language or URL component rather than HTML entity encoding. |
For untrusted rich HTML, the OWASP Cross Site Scripting Prevention Cheat Sheet is a better security reference than treating entity encoding as sanitization.
Missing semicolons can be context-dependent
HTML keeps historical support for a limited set of named references without a final semicolon. Parsing can also differ inside attributes when letters, digits, or an equals sign follow the candidate. The decoder therefore handles complete semicolon-terminated named references and numeric references rather than guessing every legacy named form.
The WHATWG named-character table shows the supported names, including the small historical subset that can appear without a semicolon in some parsing states.
When encoded text starts looking strange
Double encoding
Encoding < again produces &lt;. If a page displays < instead of <, trace which layer encoded an already encoded value rather than adding another decode step blindly.
Different spellings can mean the same character
An apostrophe can be written literally or with a numeric/named reference. Comparing raw source strings can therefore show a difference even when the browser displays the same character.
Entity decoding is not JSON unescaping
belongs to HTML character-reference syntax; \n and \u000A belong to JSON/JavaScript string syntax. Decode the layer that actually produced the data.
Unknown names stay visible
A semicolon-terminated candidate that the browser does not recognize is left unchanged. That makes misspellings easier to spot instead of silently inventing a character.
When the problem belongs to another encoding layer
URL percent-encoding, JSON string escapes, Base64, and HTML character references solve different representation problems. Following the data from its source to its final destination usually makes it clear which layer needs attention.