HTML entities exist so reserved characters survive being placed inside HTML. < is <, & is &, © is ©. Encoding protects against accidental tag injection when you display user-supplied text; decoding lets you read what's actually in a payload from someone else's server.
HTML entity encode & decode
HTML entities exist so that <, >, &, and a long tail of named characters survive being placed inside HTML. Use it to escape user-supplied content, not for display formatting.
HTML entity encode & decode
Escape &, <, >, ", ' for HTML, or decode common named and numeric entities back. The decoder uses the browser's own parser, so it understands the full named-entity table.
Raw text
Encoded
<strong class="bwh">"Practical guides" — no fluff.</strong>
Common use cases
Displaying code samples
<pre> blocks need every < and > to be entity-encoded or the browser parses them as tags and your sample becomes invisible.
Sanitizing form input for display
If you’re going to echo user input back to the page, encode it first. Most modern frameworks do this for you; some legacy stacks do not.
Decoding what an upstream service sent
Old WordPress feeds, RSS, certain XML serializers — they over-encode for safety, you need to un-do it for display.
How to use this tool
- 1 Toggle Encode or Decode.
- 2 Paste text — we update live.
- 3 Copy the result.
Frequently asked questions
Why does the decoder handle named entities like Å?
We delegate decoding to the browser’s HTML parser via a hidden textarea. That gives us the full named-entity table for free — the same one the rendering engine uses for actual pages.
Is encoding alone enough to prevent XSS?
Necessary but not sufficient. Encoding fixes the most common reflected-XSS vector. A Content Security Policy plus a sane templating engine handle the rest.
Do I need to encode inside <textarea> or <title>?
Yes — those are not script contexts, but the browser still interprets entities. Encode user input before it lands in any HTML position.