Convert special characters into safe HTML entities, or decode HTML entities back into readable text.
Characters like <, >, and & have special meaning in HTML markup. Encoding them as entities displays them as literal text instead of being interpreted as HTML syntax.
Cross-site scripting (XSS) is a security vulnerability from injected malicious HTML/JavaScript. Encoding user-supplied text as entities before display is a standard defense against this class of attack.
Yes, the decoder handles both numeric entities (') and common named entities (&, ©, ™, and more).
&, <, and > into their safe entity form, or "Decode Entities" to turn entities like & back into readable characters.
This tool converts special characters into their HTML entity equivalents (encoding), or converts HTML entities back into their original characters (decoding). It's essential for safely displaying text that contains characters with special meaning in HTML markup.
Certain characters — particularly <, >, and & — are reserved in HTML because they're used to define tags and entities themselves. If you want to display a literal "<" character in a webpage's text content rather than having it interpreted as the start of a tag, you need to encode it as <. HTML entities provide this escape mechanism for reserved characters, as well as a way to represent characters that might not be easily typed (like curly quotes, em dashes, or trademark symbols).
Beyond just correct rendering, encoding is a critical security practice. If a website displays user-submitted text without encoding it first, and that text happens to contain HTML or JavaScript, the browser will interpret and potentially execute it — this is the basis of cross-site scripting (XSS) attacks. Encoding special characters before inserting user-supplied content into a page is one of the most fundamental defenses against this vulnerability, ensuring that user input is always treated as plain text, never as executable markup.
All encoding and decoding happens directly in your browser — your text is never sent to a server.
The encoder targets the five characters that actually matter for safe HTML output: &, <, >, ", and '. Each occurrence is replaced with its corresponding named or numeric entity — ampersand first, so that encoding a character like < doesn't accidentally double-encode the ampersand inside its own entity. These five characters cover every case where HTML markup could be misinterpreted or broken by literal text, which is why most encoding libraries, including this one, focus specifically on them rather than converting every non-ASCII character.
Decoding uses the browser's own HTML parser: the entity text is assigned to a hidden textarea element's innerHTML, and the browser decodes any valid entity — numeric ('), hexadecimal ('), or named (©, ™, —) — exactly as it would when rendering a real web page. Reading the textarea's resulting value then gives back the plain-text result. This approach means the decoder supports the full range of entities a browser recognizes, not just a short hardcoded list.
A named entity like & is easier for a human to read in source code, while a numeric entity like & references a character by its Unicode code point directly and works even in contexts that don't recognize the full set of named entities. Both forms decode to the same character, and this tool's decoder handles either form without needing to know in advance which one was used.
Decoding is useful when you have raw HTML source — copied from a page's view-source, exported from a CMS, or pulled from an API response — and need to read or process the actual text content without the entity escaping getting in the way. It's also common when working with RSS feeds or scraped data, where text is frequently delivered already entity-encoded.
When building a web form or comment system, any text a user types needs to be encoded before being inserted back into the page's HTML, otherwise a user typing something like <script> could break the page layout or, in a real application without proper safeguards, enable a cross-site scripting attack. Testing how your own encoding logic behaves against tricky inputs — strings with mixed quotes, ampersands, and angle brackets — is easy to do here before wiring it into actual application code.
HTML entity encoding and URL encoding (percent-encoding) solve different problems and are not interchangeable: HTML entities make text safe to place inside HTML markup, while URL encoding makes text safe to place inside a URL. A string destined for a query parameter needs URL encoding; the same string destined for the visible text of a web page needs HTML entity encoding. Mixing the two up is a common source of bugs when handling user input across different parts of an application.