Escape text into HTML-safe entities (< & …) or decode entities back to characters. Prevents broken markup and XSS.
Text • HTML entities
Encoding and decoding share the page, so any result can be pasted straight back to confirm it round-trips to the text you started with — the quickest check that nothing was mangled.
Results are recalculated on every keystroke, with no submit step and no page reload, so a value can be adjusted until the answer looks right rather than guessed once.
Everything runs in your browser — no account, no uploads, nothing leaves your device.
HTML encoding converts characters that have special meaning in markup — &, <, >, quotes — into safe HTML entities such as & and <. This lets you display code or symbols literally on a web page and is a basic defense against cross-site-scripting (XSS) when outputting user-supplied content.
Web developers and content editors use it to paste code samples, fix broken markup, and sanitize text. This tool escapes text into entities and decodes entities back to characters, instantly in your browser.
HTML encoding replaces characters that have structural meaning in markup with entity references, so that they display as text rather than being parsed as tags. Five characters matter: the angle brackets that delimit tags, the ampersand that begins an entity, and both quote marks that delimit attribute values. This is the primary defence against cross-site scripting: escaping user input before rendering it means an injected `<script>` tag is displayed rather than executed. The escaping must be applied at output, in the context where the data is used, not at input.
& → & (must be escaped FIRST, or later escapes are double-encoded)< → < · > → >" → " · ' → 'Numeric form: &#nnn; decimal or &#xhh; hexadecimalwhere:
Assumptions: HTML escaping is not sufficient for other contexts: data placed inside a script block, a URL or a CSS value needs its own encoding. Escaping for the wrong context is a common source of vulnerabilities that look defended.
Escape user input containing markup, in the correct order.
ResultDisplayed as text: <a href="x">Tom & Jerry</a>
Order matters absolutely. Escaping < before & would produce < and then convert its ampersand, giving < — which displays as "<" rather than "<". Every correct implementation escapes the ampersand first.
Only five characters have special meaning in markup, and the named entities for them — for ampersand, the angle brackets and the two quote marks — are what encoding produces. Everything else can be written as a numeric reference instead, in decimal or in hexadecimal, which is why the same character can legitimately appear in three different escaped forms in the same document and still render identically.
The failure that matters is applying the right escaping in the wrong place. HTML escaping makes text safe between tags, but it does not make text safe inside a JavaScript string, inside a URL, or inside an unquoted attribute, each of which terminates on different characters. Output that is escaped once and then dropped into a script block is a well-known route to exactly the injection that escaping was supposed to prevent, which is why encoding has to be chosen for the destination rather than applied once at the source.
The other recurring bug is double encoding. Escaping an already-escaped string turns an ampersand into its entity a second time, so the reader sees the raw entity text on the page instead of the character. Decoding twice causes the mirror-image problem and can resurrect a tag that was deliberately neutralised — which is why escaping belongs at the moment of output, once, rather than being applied defensively at every layer.