HTML Entity Encode/Decode

About HTML Entity Encode/Decode

The Five Characters That Must Be Encoded

These five characters have special meaning in HTML. If user-supplied text contains any of them and is inserted into a page without encoding, the browser will interpret them as HTML syntax rather than display them as text.

Character	Named Entity	Numeric Entity	Why It Must Be Encoded
&	&	&	Starts an entity reference - without encoding, © would render as the copyright symbol
<	&lt;	&#60;	Opens an HTML tag - <script> would execute code
>	&gt;	&#62;	Closes an HTML tag
"	&quot;	&#34;	Terminates an attribute value in double quotes
'	&apos;	&#39;	Terminates an attribute value in single quotes

Encoding these five characters is the minimum required for safe HTML output. The & character is the most commonly missed - any literal ampersand in HTML text content should be &, even if it is not followed by a valid entity name.

Three Types of Entity References

HTML supports three different syntaxes for entity references. All three produce the same result in the browser, but they have different use cases.

Type	Syntax	Example	Result	Notes
Named	&name;	©	Copyright symbol	Human-readable, limited to defined names
Decimal	&#number;	©	Copyright symbol	Uses Unicode code point in base 10
Hexadecimal	&#xHEX;	©	Copyright symbol	Uses Unicode code point in base 16

Named entities are easier to read in source code but only cover about 2,200 characters. Numeric entities can represent any of the 149,000+ Unicode characters. Hexadecimal is often preferred because Unicode charts and programming languages typically show code points in hex.

Common Named Entities

Entity	Character	Description
 	Non-breaking space	Prevents line break between two words
—	Em dash	Long dash used in punctuation
–	En dash	Medium dash for ranges (1-10)
« / »	Guillemets	Used as quotation marks in some languages
©	Copyright symbol	Used in footer notices
®	Registered trademark	Circle-R symbol
™	Trademark	Superscript TM
…	Ellipsis	Three dots as single character
€	Euro sign	European currency symbol
£	Pound sign	British currency symbol

HTML Encoding and XSS Prevention

Cross-site scripting (XSS) is one of the most common web security vulnerabilities. It happens when user input is inserted into a page without proper encoding, allowing an attacker to inject executable scripts.

Context	Dangerous Input	What Happens Without Encoding	Safe Output
Text content	<script>alert('xss')</script>	Script executes in visitor's browser	&lt;script&gt;alert('xss')&lt;/script&gt;
Attribute value	" onmouseover="alert('xss')	Event handler injected into element	&quot; onmouseover=&quot;alert('xss')
URL attribute	javascript:alert('xss')	Script runs when link is clicked	Reject entirely - encoding is not enough

HTML entity encoding handles text content and attribute value contexts. For URLs (href, src attributes), you must also validate the URL scheme - encoding a javascript: URL does not make it safe. For JavaScript string contexts, you need JavaScript-specific escaping instead.

Encoding in Different Contexts

Context	Encoding Needed	Tool
HTML text content	HTML entity encoding	This tool
HTML attribute values	HTML entity encoding + quote the attribute	This tool
URL query parameters	Percent encoding (encodeURIComponent)	URL Encoder
JSON values	JSON string escaping	JSON Formatter
Base64 transport	Base64 encoding	Base64 Encoder

Using the wrong encoding for the context is a security risk. HTML encoding in a URL context or URL encoding in an HTML context both leave the output vulnerable to injection.

Encoding in Programming Languages

Language	Function	Example
JavaScript (DOM)	textContent (auto-escapes)	element.textContent = userInput
JavaScript (manual)	No built-in - use a library or replace()	str.replace(/&/g, '&amp;').replace(/</g, '&lt;')
Python	html.escape()	html.escape('<script>')
PHP	htmlspecialchars()	htmlspecialchars($input, ENT_QUOTES, 'UTF-8')
Ruby	CGI.escapeHTML()	CGI.escapeHTML('<b>bold</b>')
Go	html.EscapeString()	html.EscapeString("<script>")

Modern template engines (React, Vue, Angular, Jinja2, Razor) encode output by default. The dangerous patterns are raw HTML insertion: dangerouslySetInnerHTML in React, v-html in Vue, and |safe in Jinja2. These bypass encoding and should only be used with trusted content.

When to Use Named vs Numeric Entities

Situation	Recommended	Why
The 5 critical characters	Named (& < etc.)	Most readable in source code
Common symbols (copyright, trademark)	Named (© ™)	Widely recognized
Rare Unicode characters	Numeric (☃ for snowman)	No named entity exists for most Unicode characters
UTF-8 document with non-ASCII characters	Use the character directly	If the document encoding is UTF-8, entities are unnecessary for display characters

Worked Example: Encoding a User Comment

A user submits the comment <b>Check this & see!</b> on a blog. If the site renders that string raw, the browser treats <b> as a bold tag and & as the start of an entity. The page looks fine in this harmless case, but the same channel lets an attacker submit <script>fetch('/api/keys')</script> and run code in every visitor's session.

Encode step by step: First replace every & with & (order matters - do this first or you double-encode later entities). Next swap < for <, > for >, " for ", and ' for '. The comment becomes <b>Check this & see!</b>. The browser now shows the literal angle brackets and ampersand instead of applying them as markup. Drop that output into your page template and the attack surface for the comment field disappears.

Why Entity Decoding Is Harder Than It Looks

Decoding is trickier than encoding. A decoder needs to handle named entities with and without trailing semicolons, decimal entities like ©, hexadecimal entities like © or ©, surrogate pairs for characters above U+FFFF, and legacy entities the HTML parser still recognises for backward compatibility. This tool uses the browser's own HTML parser (via a hidden textarea element) to match the behaviour of real rendering engines, so edge cases like ∉ versus ¬in resolve correctly.

Common mistakes when rolling your own decoder: assuming every entity ends in a semicolon (the parser accepts &copy in some contexts), treating 
 and 
 as safe (they break JavaScript string literals), or iterating replacements in a way that lets < become < after two passes. Round-tripping through the browser's parser avoids all of these.

How Many Named Entities Exist?

The HTML Living Standard defines 2,231 named character references, according to the WHATWG named-characters table. That covers common symbols (© ® ™), Greek letters (α β), mathematical operators (∑ ∫ ∞), and arrows. Unicode itself defines over 149,000 code points as of Unicode 16.0 (September 2024), so named entities cover only about 1.5% of Unicode. For anything outside that set - emoji, CJK ideographs, rare mathematical symbols - use numeric references or the raw UTF-8 character if your document declares that encoding.

Named entities are case-sensitive: &Copy; (capital C) produces the double-struck capital C, while © produces the copyright symbol. Typo-prone pairs like < versus ≪ (less-than with dot) and ⊃ versus ⊇ (superset versus subset-equal) trip up hand-written markup regularly. Numeric entities sidestep this entirely.

When You Do Not Need to Encode

Modern frameworks encode output by default, so you do not need to pre-encode text before passing it into JSX, Vue templates, or Jinja2. The framework's template engine handles it at render time. You only need this tool when you are building HTML by string concatenation (legacy templates, email generators, static file exports), pasting text into an HTML source file manually, or sanitising content that will be inserted via innerHTML. For the reverse direction - decoding - common scenarios include reading scraped HTML, processing RSS feeds, or debugging API responses that return HTML-encoded strings.

For URL components, use the URL Encoder and Decoder instead - percent encoding and HTML entity encoding are not interchangeable. For converting between HTML and Markdown or prettifying tangled HTML, reach for the HTML Prettifier after decoding.

Common Mistakes to Avoid

• Encoding twice. Running encoded text through an encoder again turns & into &. Always know whether a string has already been encoded before processing it.
• Using HTML encoding in a JavaScript string. </script> inside a JavaScript block ends the script tag regardless of HTML encoding. Use JavaScript string escapes (\u003c/script\u003e) or serve the data via a JSON endpoint.
• Trusting ' in old browsers. Internet Explorer 8 and older did not recognise '. Use ' for single quotes if you need to support ancient browsers - modern browsers handle both.
• Encoding inside attribute values but leaving the attribute unquoted. <a href=/page class=foo> is valid HTML but lets an attacker inject attributes by including a space in the value. Always quote attribute values.
• Assuming server-side encoding is enough. Reactive UI frameworks re-render based on client state. If state contains raw HTML, a server encode does not help - the client must handle it too.

All processing happens in your browser. Your text is never sent to any server, making this tool safe for encoding sensitive content or debugging security issues.

Sources

• WHATWG HTML Living Standard - Named Character References
• WHATWG HTML Living Standard - Character Reference Parser State
• MDN Web Docs - HTML Entity Glossary
• OWASP - Cross-Site Scripting (XSS)
• OWASP XSS Prevention Cheat Sheet
• Unicode 16.0.0 Specification