HTML Entity Converter — Encode & Decode HTML Entities

HTML entities are short codes that represent characters with special meaning in HTML syntax. The most critical ones are the angle brackets (< and >), which the browser interprets as the start and end of HTML tags, and the ampersand (&), which begins every entity reference. When you want to display these characters as visible text rather than having the browser parse them as markup, you must use their entity equivalents: &lt; for <, &gt; for >, and &amp; for &. Other commonly encoded characters include the double quote (&quot;) and apostrophe (&apos;), which matter inside attribute values. HTML also supports hundreds of named entities for symbols and accented letters — for example, &copy; for ©, &eacute; for é, and &mdash; for an em dash. Numeric entities (&#60; or &#x3C;) work as an alternative when a named form does not exist. Understanding entities helps you write more robust, standards-compliant HTML that displays correctly across all browsers and character sets.

HTML entities come in two flavors: named and numeric. Named entities use a descriptive keyword, such as &amp; (ampersand), &lt; (less-than), and &nbsp; (non-breaking space). They are human-readable and widely recognized, but not every character has a named form. Numeric entities reference a character by its Unicode code point, either in decimal form (&#38; for &) or hexadecimal form (&#x26; for &). Every Unicode character can be expressed numerically, making numeric entities more universal. Both forms are fully equivalent to browsers — &amp; and &#38; both render as an ampersand. The choice between them is mostly stylistic: use named entities for readability in hand-written HTML, and numeric entities when you need to represent a character that has no name or when generating HTML programmatically without worrying about entity name lookups.

It is important to distinguish between HTML entity encoding and character encoding. Character encoding (such as UTF-8) defines how text bytes are stored and transmitted at the byte level. As long as your page declares UTF-8 with a proper <meta charset="UTF-8"> tag and your server sends the correct Content-Type header, you can include most Unicode characters — including Japanese, emoji, and accented letters — directly in your HTML source without entity-encoding them. HTML entities, by contrast, are specifically for escaping characters that have syntactic significance in HTML (&, <, >) or that must appear inside attribute values safely. A common misconception is that all non-ASCII characters must be entity-encoded; with modern UTF-8 pages, only the handful of HTML syntax characters truly require escaping.

Cross-site scripting occurs when an attacker injects malicious HTML or JavaScript into a web page that is then executed in another user's browser. The classic example: a comment form that accepts user input and renders it directly into the page. If a user submits <script>alert("hacked")</script> and the application outputs it without encoding, the browser executes the script rather than displaying it as text. This can allow attackers to steal session cookies, redirect users to phishing sites, log keystrokes, or deface pages. XSS vulnerabilities are ranked among the top web security risks in every edition of the OWASP Top 10. The fundamental cause is always the same: untrusted data is placed into an HTML context without being properly escaped.

By converting characters like < and > into &lt; and &gt; before inserting user-supplied data into a page, you ensure the browser renders them as visible text rather than parsing them as HTML tags. A script tag becomes &lt;script&gt;alert()&lt;/script&gt;, which displays harmlessly on screen. This technique is called output encoding and is the first and most reliable layer of XSS defense. It must be applied in the correct context: HTML-entity encoding works for text nodes and attribute values, but URL encoding is needed for href attributes, and JavaScript string escaping is needed inside <script> blocks. Using a single encoding strategy for all contexts is insufficient. Modern web frameworks like React, Angular, and Vue automatically HTML-encode dynamic content in templates, but you must still be careful with features that allow raw HTML injection, such as React's dangerouslySetInnerHTML.