HTML Entities Encoder & Decoder

Convert HTML special characters to their entity equivalents and back. All processing is done in your browser.

Common HTML Entities
CharacterEntity NameEntity Number
<&lt;&#60;
>&gt;&#62;
&&amp;&#38;
"&quot;&#34;
'&apos;&#39;
(non-breaking)&nbsp;&#160;
©&copy;&#169;
®&reg;&#174;

Frequently Asked Questions

HTML has reserved characters like <, >, and & that the browser interprets as markup. To display them as literal text you must encode them as entities. This is also a critical security practice to prevent Cross-Site Scripting (XSS) attacks when outputting user-supplied content in HTML.

Named entities use a word reference like &amp; or &copy; — easier to read but only defined for specific characters. Numeric entities use the Unicode code point (&#38; decimal or &#x26; hex) and can represent any Unicode character.

The essential entities every developer should know: &lt; (<, less-than), &gt; (>, greater-than), &amp; (&, ampersand), &quot; (", double quote — needed inside attribute values), &apos; (', apostrophe — HTML5 only), and &nbsp; (non-breaking space — prevents line breaks between words). For currency: &copy; (©), &reg; (®), &euro; (€), &pound; (£). Always encode at minimum < > & and " in HTML output from user data.

Cross-Site Scripting (XSS) occurs when attacker-controlled text is injected into a page and interpreted as HTML or JavaScript. If a user submits <script>alert(1)</script> and you output it unescaped, the browser executes it. Encoding it to &lt;script&gt;alert(1)&lt;/script&gt; makes the browser render it as visible text instead. This is called output encoding — the primary defense against reflected and stored XSS. Use your framework's built-in escaping functions: PHP's htmlspecialchars(), Twig's |e filter, React's JSX auto-escaping, or Django's template engine.

The terms are often used interchangeably, but have a subtle distinction. Encoding transforms data from one representation to another (e.g., converting < to &lt;) using a well-defined scheme that is fully reversible. Escaping is a broader term for making a special character literal — sometimes via a prefix (backslash in strings) rather than a substitution. In HTML context-output encoding, you transform characters so the browser never treats user data as markup — both terms describe this same operation and are used interchangeably in security documentation.

XML only has five predefined entities: &lt;, &gt;, &amp;, &apos;, and &quot;. HTML-specific named entities like &nbsp; or &copy; are not valid in standard XML — they will cause a parsing error unless declared in the document's DTD. To include any character safely in XML, use numeric character references (&#160; for non-breaking space, &#169; for ©) or declare custom entity references in the DTD, or simply use UTF-8 and include the characters directly.

HTML email clients have inconsistent and often poor HTML/CSS support. Use named entities for the core five (&lt; &gt; &amp; &quot; &apos;) and numeric entities for all other special characters — never rely on a named entity being recognized by all email clients. Non-breaking spaces (&nbsp;) are widely supported and useful for spacing. For currency symbols, degree signs, and other typographic characters, numeric entities (&#8364; for €) are the safest choice. Avoid relying on character set declarations to include bare Unicode — some clients strip or re-encode them.

Browsers use a lenient HTML5 parsing algorithm. An unknown named entity like &foo; is treated as literal text and rendered as-is. A malformed entity (missing semicolon or unrecognized name) may be partially rendered depending on the parser. This lenient behavior is intentional for backwards compatibility but means you should not rely on unknown entities being safely ignored in a security context — a browser's tolerance can vary and may produce unexpected output. Always use only valid, well-known entity references in your markup.

No — HTML entities are only interpreted inside HTML documents, not inside JavaScript string literals. If you write const s = "&amp;";, the variable s contains the literal string &amp;, not &. When inserting JavaScript values into the DOM, use element.textContent = value (which auto-escapes) rather than element.innerHTML = value (which interprets HTML). When you must set innerHTML, encode with a function like PHP's htmlspecialchars() server-side, or use the browser's document.createElement API client-side to build nodes safely.

For security, you must encode at minimum: <, >, &, ", and ' when outputting to HTML. However, OWASP recommends aggressive encoding — encoding all non-alphanumeric ASCII characters — when embedding user content in JavaScript contexts or attribute values, because the required encoding set depends on the HTML context (element content, attribute value, script block, URL). Using your framework's context-aware auto-escaping is safer than manually deciding which characters are "dangerous."

About This HTML Entity Encoder / Decoder

This free HTML entity tool converts special characters such as <, >, &, ", and ' to their HTML entity equivalents, and decodes HTML entities back to their original characters. Both named entities (&amp;) and numeric entities (&#38;) are supported.

HTML encoding is essential for displaying user-supplied content safely in a web page without introducing XSS vulnerabilities. Decoding is useful when working with scraped HTML, email templates, or CMS content that contains escaped entities.

When to use this tool

  • Escaping user input before rendering it inside HTML
  • Decoding HTML-encoded content received from an API
  • Converting angle brackets in code examples for display
  • Debugging double-encoded HTML in email templates

How HTML Entity Encoding Works

HTML entity encoding replaces special characters with safe sequences so the browser renders them as text rather than interpreting them as markup.

Scan for Reserved Characters

The input is scanned character by character. HTML's five reserved characters — &, <, >, ", and ' — must always be encoded to be safe in HTML context.

Replace with Entities

Each reserved character is replaced with its named entity (e.g., <&lt;). Optionally, non-ASCII characters are also replaced with numeric entities (&#xxx;).

Safe for HTML Insertion

The encoded string can be inserted into any HTML context — inside tags, attributes, or text nodes — without risk of breaking the document structure or triggering XSS.

Common Use Cases

XSS Prevention

The most critical use of HTML entity encoding is neutralizing user-supplied input before rendering it in HTML. Encoding < and > prevents injected script tags from executing.

Code Samples in Documentation

When writing technical blog posts, READMEs, or wikis in HTML, code samples containing <tags> must be entity-encoded so they display as literal text rather than parsed HTML.

HTML Email Templates

Email clients are strict parsers. Dynamic content in email templates — names, addresses, product titles — must be entity-encoded to prevent accidental HTML breakage or injection.

CMS and Template Engines

Twig, Blade, and similar template engines auto-escape output by default. This tool helps verify how a template engine would encode a given value, or prepare raw HTML strings for insertion.

HTML Attribute Values

Dynamic values in HTML attributes (titles, alt text, data attributes) may contain quotes. Encoding " and ' prevents attribute injection attacks and malformed markup.

Decoding Received HTML

Some APIs or data sources return HTML-encoded text. Use the Decode tab to convert entities back to plain text for processing or display outside of HTML context.

Related Articles

View all articles
Double Encoding: Why "&amp;amp;" Shows Up, and Why the "Quick Fix" Can Be Dangerous

Double Encoding: Why "&amp;amp;" Shows Up, and Why the "Quick Fix" Can Be Dangerous

"&amp;amp;" appearing on a webpage instead of "&" is one of the most common HTML-entity bugs — an ampersand encoded twice, because encoding got applied at multiple uncoordinated points in a pipeline. Here's why this happens, why "encode once, at output, as late as possible" is the fix, and why "fixing" double-encoding by removing encoding from the wrong stage can quietly turn a cosmetic bug into an XSS vulnerability.

Jun 17, 2026
Unicode Fundamentals: ASCII History, UTF-8 Encoding, Byte Order Marks, and Why Mojibake Happens

Unicode Fundamentals: ASCII History, UTF-8 Encoding, Byte Order Marks, and Why Mojibake Happens

ASCII was designed in 1963 for 7-bit telegraph machines. Every country's attempt to extend it to 8 bits was incompatible, producing mojibake when files crossed systems. Here's how Unicode solved the problem, why UTF-8 became dominant (backward compatibility with ASCII), what byte order marks are, and what character encoding corruption actually looks like.

Jun 14, 2026
XSS and HTML Encoding: The Five Contexts That Require Different Escaping

XSS and HTML Encoding: The Five Contexts That Require Different Escaping

XSS is still the most common web vulnerability — and unescaped HTML is the mechanism. Here's how cross-site scripting actually works, the five encoding contexts that require different treatment, why React is safe by default but PHP isn't, and how CSP adds a second layer.

Jun 9, 2026
HTML Entities — Encode & Decode Special Characters for Correct, Safe HTML

HTML Entities — Encode & Decode Special Characters for Correct, Safe HTML

Learn what HTML entities are, why they exist, the most common named entities, how numeric entities work for any Unicode character, and when modern UTF-8 pages don't need them — with a free HTML entities tool.

Jun 7, 2026
HTML Entities — Encode & Decode Special Characters Correctly

HTML Entities — Encode & Decode Special Characters Correctly

Learn what HTML entities are, which characters always need encoding, how to use &lt;, &amp;, &nbsp;, and special symbols correctly — with a free HTML entities encoder/decoder tool.

Jun 6, 2026