HTML entities are the escape hatches of the web: < renders as <, & renders as &, and © becomes ©. They exist because characters like <, > and & have structural meaning in HTML — without entities, there would be no way to display them as ordinary text.
Encoding matters every time user-supplied text meets a web page. A comment containing <script> must be encoded before it is inserted into HTML, or the browser will execute it — the classic cross-site scripting (XSS) attack. Decoding matters when you scrape or migrate content: CMS exports, RSS feeds and email templates are full of entities that need converting back to real characters before further processing. The same class of problem appears in XML documents — our XML formatter validates structure while you fix escaping.
This free tool converts in both directions using the browser’s own entity tables, so named entities (€), decimal references (€) and hex references (€) are all handled correctly. Everything runs locally; your text is never sent anywhere.
How to use the HTML entity encoder / decoder
- Paste your text into the input box — raw text to encode, or entity-filled markup to decode.
- Click “Encode to entities” to convert
< > & " 'and special characters into their entity equivalents. - Or click “Decode from entities” to turn
<,©and friends back into readable characters. - Use Swap to flip the result back into the input for a quick round-trip check.
- Copy the result straight into your code, CMS, or email template.
Key features & benefits
- Two-way conversion. Encode and decode with dedicated buttons — no mode confusion, no re-pasting.
- Full entity support. The browser’s native tables cover every named entity plus decimal and hexadecimal numeric references.
- XSS-safe by construction. Encoding uses text assignment, never HTML parsing, so malicious input cannot execute during conversion.
- Round-trip check. The Swap button lets you encode, then decode, and confirm you get the original text back byte-for-byte.
- Private by default. All conversion happens in your browser’s memory; snippets of proprietary code stay on your machine.
- One-click copy. Results copy to your clipboard with a fallback for older browsers.
When to encode vs. decode (with examples)
Choosing the wrong direction is the entire bug category this tool prevents. Here is the rule of thumb:
Encode when text goes into HTML
Blog comments, form submissions, error messages containing user input — anything rendered inside a page must be encoded first. Tom & Jerry becomes Tom & Jerry; without that step, a stray < can break your layout or worse.
Decode when text comes out of HTML
Scraped article text reading — should become an em dash before you analyze or republish it. The same applies to API responses that arrive HTML-escaped — and our JSON formatter helps inspect those escaped payloads. If you are converting whole documents rather than snippets, our HTML to Markdown converter handles tags and entities together.
Watch out for double encoding
Encoding & again produces &amp;, which renders literally as “&” — the telltale sign of text encoded twice. If your page shows raw entity codes, decode once and check whether the source was already encoded. Our URL encoder/decoder covers the sibling problem of percent-encoded text.
Frequently asked questions
What is the difference between < and <?
Nothing, semantically — both represent the character <. < is a named entity (easier to read), while < is a numeric character reference using the decimal code point. Hexadecimal < is a third spelling of the same character. This decoder accepts all three.
Do I need to encode every special character?
Strictly, only &, <, >, and quotes inside attributes are required for correct parsing. Encoding accented characters like é is optional in UTF-8 documents but harmless, and some teams encode everything for maximum compatibility with legacy systems.
Will encoding prevent XSS attacks?
Encoding user text before inserting it into HTML is the single most important XSS defense, and it neutralizes the classic <script> injection. It is not the whole story, though — JavaScript contexts, URLs, and event handlers need their own escaping rules. Treat encoding as necessary but not sufficient.
Why does my page show “&” literally?
That is double encoding: an ampersand was encoded to &, then encoded again. Paste the text here, decode once, and check whether the result looks right. Then fix the pipeline so encoding happens exactly once — usually at the final output step.
Can entities represent emoji?
Yes, via numeric references to the code point — 😀 is 😀. Named entities do not exist for most emoji, so numeric references are the standard approach. Note that very old systems may not render newer emoji regardless of encoding.
How It Works: Under the Hood
HTML reserves five characters with structural meaning: < > & ” ‘. The encoder replaces each with its entity reference — named (<), decimal numeric (<), or hex numeric (<) — so browsers render the literal character instead of parsing it as markup. Decoding reverses the mapping, including the 2,000+ named entities in the HTML5 spec (© € — etc.). The tricky part is context: text nodes, attribute values, and URLs each have different encoding rules, and UTF-8 multibyte characters (emoji, CJK) encode as single code points, not byte sequences. A correct encoder processes input as Unicode code points and escapes only what’s structurally dangerous in the target context.
Real-World Use Cases
- Bloggers posting code samples: paste a JavaScript snippet into WordPress without the browser eating your