If you have ever seen < where you expected a <, or & in place of an ampersand, you have met HTML entities. They look like clutter, but they are doing something important: keeping your markup valid and your pages safe from a whole category of security attacks. This guide explains what they are, why they matter, and when to use them.
The Core Problem HTML Entities Solve
HTML uses certain characters as structural markup. The angle brackets < and > define tags, and the ampersand & begins an entity. So what happens when your actual content needs to contain those characters? If you write 5 < 10 directly in HTML, the browser sees < and starts looking for a tag โ and your content breaks.
HTML entities are the escape hatch. They represent a reserved character in a form the browser displays as text rather than interpreting as markup. < renders as <, > renders as >, and & renders as &. The structure stays intact and your content shows correctly.
The Characters That Matter Most
You do not need to encode everything โ only the characters that carry special meaning:
| Character | Entity | Why encode it |
|---|---|---|
| < | < | Starts a tag |
| > | > | Ends a tag |
| & | & | Starts an entity |
| " | " | Ends an attribute value |
| ' | ' | Ends an attribute value |
In page text, the first three are essential. Inside attribute values, the quotes matter too.
Named vs. Numeric Entities
There are two ways to write an entity:
- Named โ a readable alias, like
©for ยฉ, for a non-breaking space, or♥for โฅ. Easy to recognize but limited to a defined list. - Numeric โ the character's Unicode code point, like
©for ยฉ or<for <. These work for any character, even ones without a named alias.
Use named entities when they exist for readability, and numeric ones for anything else.
The Security Angle: Preventing XSS
This is the part that turns a formatting detail into a security necessity. Cross-site scripting (XSS) is an attack where a malicious user submits input containing HTML or a <script> tag, and the site renders it as live markup โ running the attacker's code in other users' browsers.
Encoding user input defuses this. If someone submits <script>steal()</script> and you encode it before display, the browser shows the literal text instead of executing it. The rule is simple and absolute: always encode untrusted text before inserting it into a page.
Warning: Never render user-supplied content as raw HTML unless you have deliberately sanitized it. Entity-encoding by default is the safe habit that prevents most XSS bugs.
Step-by-Step: Encode and Decode
Use the HTML Entity Encoder, which runs in your browser.
- Paste your text containing special characters.
- Click Encode to convert reserved characters to entities, ready to drop into HTML.
- To reverse it, paste entity-encoded text and Decode to read the original.
- Copy the result into your template or content.
Where Entities Fit Among Encodings
HTML entity encoding protects the HTML context specifically. It is a sibling of URL encoding, which protects URLs, and Base64, which makes binary safe for text channels. Each guards a different environment โ using the wrong one leaves a gap, so match the encoding to where the data will live.
Common Mistakes to Avoid
- Not encoding user input. The classic XSS mistake. Encode untrusted text every time.
- Double-encoding. Encoding already-encoded text turns
&into&amp;. Encode once. - Forgetting attribute quotes. Inside attributes, unencoded quotes can break out of the value.
- Using the wrong encoding. HTML entities do not protect URLs, and URL encoding does not protect HTML.
Conclusion
HTML entities keep reserved characters from breaking your markup and, crucially, stop untrusted input from becoming executable code. Encode <, >, and & in text (plus quotes in attributes), prefer readable named entities where they exist, and make entity-encoding of user input an automatic habit. It is a small practice that prevents both broken pages and serious security holes.
Encode or decode now with the free HTML Entity Encoder โ private and instant.