Dev Tools

HTML Entity Encoder & Decoder

Encode special characters to HTML entities or decode entities back to readable text. Supports named and numeric entities.

Quick Answer

The 5 essential HTML entities: & (ampersand), < (less than), > (greater than), " (double quote), ' (apostrophe).

Common HTML Entities Reference

CharacterNamedNumericDescription
&&&Ampersand
<&lt;&#60;Less than
>&gt;&#62;Greater than
"&quot;&#34;Double quote
'&#39;&#39;Single quote / Apostrophe
(space)&nbsp;&#160;Non-breaking space
©&copy;&#169;Copyright
®&reg;&#174;Registered
&trade;&#8482;Trademark
&ndash;&#8211;En dash
&mdash;&#8212;Em dash
&hellip;&#8230;Ellipsis

About This Tool

The HTML Entity Encoder and Decoder is a developer utility that converts special characters to their HTML entity equivalents and back. Whether you are preparing content for a web page, sanitizing user input, building email templates, or debugging encoded strings in API responses, this tool handles the conversion instantly in your browser with zero server-side processing.

What Are HTML Entities?

HTML entities are special notation sequences that represent characters in HTML documents. They begin with an ampersand (&) and end with a semicolon (;). Entities exist because certain characters have special meaning in HTML syntax: the less-than sign (<) opens a tag, the greater-than sign (>) closes one, the ampersand itself starts an entity reference, and quotation marks delimit attribute values. Without entities, using these characters in visible text content would confuse the browser's HTML parser. Entities come in two forms: named entities like &amp; that use mnemonic keywords, and numeric entities like &#38; that use the character's Unicode code point. Both are universally supported across all browsers and are functionally identical.

Why Encoding Matters for Web Security

HTML entity encoding is one of the primary defenses against Cross-Site Scripting (XSS) attacks. XSS is consistently ranked among the top web application vulnerabilities by the OWASP Foundation. When a website displays user-provided content without encoding it first, attackers can inject malicious HTML and JavaScript that executes in other users' browsers. Proper encoding converts potentially dangerous characters like < and > into their entity equivalents, rendering them as visible text rather than executable markup. While modern frameworks often handle encoding automatically, developers must understand the underlying mechanism to identify when automatic encoding might be bypassed and to manually encode content in edge cases such as inline scripts, URLs, or CSS contexts.

Named vs. Numeric Entities

Named entities are easier to read in source code. &copy; is immediately recognizable as a copyright symbol, while &#169; requires you to know the Unicode code point. However, named entities are limited to the set defined by the HTML specification, which covers common punctuation, mathematical symbols, Latin characters, and Greek letters, but does not include every Unicode character. Numeric entities can represent any of the 149,000+ characters in the Unicode standard, including emoji, CJK ideographs, and obscure technical symbols. Hexadecimal numeric entities (&#x00A9;) are also supported and are sometimes preferred because Unicode code charts list characters in hexadecimal. This tool lets you choose between named and numeric encoding depending on your requirements.

Encoding in Modern Development

In the era of UTF-8, which is now the default encoding for HTML5 documents, many characters can be included directly in your source code without entities. Accented characters, CJK characters, and even emoji render correctly when the document is served with the proper Content-Type header or meta charset tag. However, the five critical HTML syntax characters (&, <, >, ", ') must still be encoded when they appear in text content or attribute values. Additionally, non-breaking spaces (&nbsp;) remain necessary for layout control, and entities are useful for inserting characters that are difficult to type or visually ambiguous in source code, such as zero-width spaces, soft hyphens, and various dash types.

Common Use Cases

Developers use this tool when embedding code snippets in blog posts or documentation, where angle brackets and ampersands must be encoded to display correctly. Email developers encode special characters for maximum compatibility across diverse email clients. Content editors encode typographic characters like em dashes, curly quotes, and ellipses when working directly with HTML source. QA engineers decode entity-encoded strings from API responses or database records to verify the underlying content. Technical writers encode HTML examples within HTML documentation, creating the necessary layers of encoding. This tool handles all these scenarios with a simple paste-and-convert workflow, saving time and eliminating manual encoding errors.

Frequently Asked Questions

What are HTML entities and why do I need them?
HTML entities are special codes that represent characters which have reserved meanings in HTML or cannot be typed directly on a keyboard. For example, the less-than sign (<) starts an HTML tag, so if you want to display a literal < on a web page, you must use the entity &lt; instead. Similarly, the ampersand (&) begins an entity reference, so it must be written as &amp; in HTML source code. Without proper encoding, browsers will misinterpret these characters as HTML markup, potentially breaking your page layout, creating security vulnerabilities (XSS attacks), or displaying content incorrectly. Entities also let you include special characters like copyright symbols, em dashes, and non-breaking spaces that may not be available on all keyboards.
What is the difference between named and numeric HTML entities?
Named entities use a human-readable keyword, like &amp; for & or &copy; for the copyright symbol. They are easier to read and remember. Numeric entities use the character's Unicode code point in decimal (&#38;) or hexadecimal (&#x26;) format. Every character that has a named entity also has a numeric equivalent, but not every character has a named entity. Numeric entities can represent any Unicode character, including emoji and characters from non-Latin scripts. Named entities are limited to a predefined set maintained by the HTML specification. Both formats are universally supported by all modern browsers. Use named entities for common characters for readability, and numeric entities when you need to represent unusual or special characters.
How does HTML entity encoding prevent XSS attacks?
Cross-Site Scripting (XSS) attacks occur when an attacker injects malicious JavaScript into a web page, usually through user-generated content like comments, form inputs, or URL parameters. If a website displays user input without encoding it, an attacker can inject code like <script>stealCookies()</script>. When the page renders, the browser executes this as actual JavaScript. HTML entity encoding prevents this by converting < to &lt; and > to &gt;, so the browser displays the text literally instead of executing it. This is why encoding user input before rendering it in HTML is a fundamental web security practice. Server-side frameworks typically include automatic encoding, but understanding the mechanism helps developers identify and fix XSS vulnerabilities.
When should I encode HTML entities vs. use UTF-8 directly?
With modern UTF-8 encoding (which is the default for HTML5), you can include most characters directly in your HTML source without entities. Characters like accented letters (e, u), CJK characters, and even emoji can be typed directly if your file is saved as UTF-8. However, you must always encode the five characters that have special meaning in HTML: & (&amp;), < (&lt;), > (&gt;), double quote (&quot;) inside attributes, and single quote (&#39;) inside single-quoted attributes. You should also use &nbsp; for non-breaking spaces where you need to prevent line breaks. Beyond these required cases, using entities for characters like &copy; or &mdash; is a matter of personal preference and coding style.
Can I use this tool to encode HTML for email templates?
Yes, this encoder is particularly useful for email development. Email clients have inconsistent support for character encodings, and many older email clients may not render UTF-8 characters correctly. Encoding special characters as HTML entities ensures they display properly across Gmail, Outlook, Apple Mail, Yahoo Mail, and other email clients. This is especially important for characters like em dashes, curly quotes, bullet points, and trademark symbols that are commonly used in marketing emails. Simply paste your text into the encoder, and it will convert any special characters to their entity equivalents. Then copy the encoded output into your email template's HTML source code.

Was this tool helpful?

. When the page renders, the browser executes this as actual JavaScript. HTML entity encoding prevents this by converting < to < and > to >, so the browser displays the text literally instead of executing it. This is why encoding user input before rendering it in HTML is a fundamental web security practice. Server-side frameworks typically include automatic encoding, but understanding the mechanism helps developers identify and fix XSS vulnerabilities."}},{"@type":"Question","name":"When should I encode HTML entities vs. use UTF-8 directly?","acceptedAnswer":{"@type":"Answer","text":"With modern UTF-8 encoding (which is the default for HTML5), you can include most characters directly in your HTML source without entities. Characters like accented letters (e, u), CJK characters, and even emoji can be typed directly if your file is saved as UTF-8. However, you must always encode the five characters that have special meaning in HTML: & (&), < (<), > (>), double quote (") inside attributes, and single quote (') inside single-quoted attributes. You should also use   for non-breaking spaces where you need to prevent line breaks. Beyond these required cases, using entities for characters like © or — is a matter of personal preference and coding style."}},{"@type":"Question","name":"Can I use this tool to encode HTML for email templates?","acceptedAnswer":{"@type":"Answer","text":"Yes, this encoder is particularly useful for email development. Email clients have inconsistent support for character encodings, and many older email clients may not render UTF-8 characters correctly. Encoding special characters as HTML entities ensures they display properly across Gmail, Outlook, Apple Mail, Yahoo Mail, and other email clients. This is especially important for characters like em dashes, curly quotes, bullet points, and trademark symbols that are commonly used in marketing emails. Simply paste your text into the encoder, and it will convert any special characters to their entity equivalents. Then copy the encoded output into your email template's HTML source code."}}]}