HTML documents are text files with a specific syntax. Certain characters — the angle brackets, the ampersand, the quotation mark — have special meaning in that syntax. When you want to display these characters as content rather than use them as markup, you need to encode them as HTML entities. Getting this right is not just about correctness; improper encoding is one of the most common causes of both broken layouts and cross-site scripting (XSS) vulnerabilities.
The Characters That Must Be Encoded
Five characters must be encoded when they appear in HTML content: the less-than sign < becomes <, the greater-than sign > becomes >, the ampersand & becomes &, the double quotation mark " becomes " (required inside double-quoted attribute values), and the single quotation mark ' becomes ' (required inside single-quoted attribute values, though ' is an HTML5 addition and ' is more universally supported).
The less-than sign is the most critical because < immediately triggers the browser's HTML parser into tag-recognition mode. If you write the text "if x < 5" in HTML without encoding, the browser attempts to interpret < 5 as the beginning of an HTML tag. Depending on the content that follows, this either silently drops the character, causes visible display corruption, or in injection scenarios, executes attacker-supplied HTML.
The ampersand is equally critical because it starts entity sequences. Writing "Tom & Jerry" without encoding causes the browser to start looking for a ; character to complete an entity. Modern browsers are lenient about bare ampersands in content, but the HTML specification requires encoding, and parsers in XML contexts (SVG, XHTML) will error on unencoded ampersands.
Named Entities vs. Numeric References
HTML entities have two forms: named (©, —, ) and numeric (©, —,  ). Named entities are readable but only exist for a subset of Unicode characters. Numeric entities (decimal © or hexadecimal ©) work for every Unicode code point. Both forms produce identical output.
Commonly used named entities include (non-breaking space,  ) for preventing line breaks between words, — (em dash, —) for typographic dashes, © (copyright symbol), & (ampersand), < and > (angle brackets), and “ and ” (left and right double quotation marks) for typographically correct quotes.
Zero-width characters and special Unicode spaces have no named entities and require numeric references. The zero-width non-joiner is ‌, and the zero-width joiner is ‍. These are used in internationalization contexts for languages that have complex joining rules. In practice, if you are working with modern UTF-8 encoded HTML, you can simply include the Unicode character directly rather than using a numeric reference.
When You Do Not Need Entities
If your HTML document declares UTF-8 encoding (via <meta charset="UTF-8">) and your file is actually saved as UTF-8, you can include most Unicode characters directly in your HTML without encoding them. Accented characters, em dashes, curly quotes, emoji, and most symbols can be typed or pasted directly. The browser will display them correctly.
The characters that genuinely require encoding regardless of charset declaration are the five structural characters listed earlier: <, >, &, " (in attributes), and ' (in single-quoted attributes). These characters have syntactic meaning in HTML and must be escaped when they appear as data rather than markup. Everything else is encoding by convention, not necessity.
Encoding in Context: Attributes and JavaScript
Encoding rules change depending on context. Inside an HTML attribute value, the encoding requirement depends on the delimiter: double-quoted attributes must encode ", while single-quoted attributes must encode '. Unquoted attributes (which you should not use) must encode spaces, equals signs, and both quote characters.
When inserting user-supplied data into HTML, always encode on output, not on input. Store the raw data and encode when rendering. Encoding on input and storing pre-encoded data leads to double-encoding bugs (the ampersand in & gets encoded again to &amp;) and makes the stored data difficult to use in non-HTML contexts like JSON APIs or plain-text emails.
JavaScript inside HTML has its own encoding context. If you are injecting a value into a JavaScript string inside a script element, HTML entity encoding is not the right approach — you need JavaScript string escaping (backslash escaping of special characters). Confusing the two contexts is a common source of both bugs and XSS vulnerabilities. Use context-appropriate encoding functions: htmlEncode() for HTML content, and JSON.stringify() for JavaScript data.
HTML entity encoding is not complicated once you understand the rule: encode the five structural characters when they appear as content, use the charset declaration to avoid unnecessary encoding of Unicode characters, and always encode on output using context-appropriate functions. An HTML entity encoder and decoder is useful for debugging display issues with special characters, verifying that form submissions are being sanitized correctly, and quickly producing the correct entity for any character.