HTML Entities Explained: The Only 5 You Must Know

HTML entities are short codes — like < for < and & for & — that tell a browser to display a character instead of interpreting it as markup. They exist because a handful of characters have jobs in HTML syntax, and the moment your content contains one of them, the browser can't tell your text from your tags.

Here's a confession from the first code-snippet page we ever shipped: the tutorial rendered beautifully right up to the first <div> in the example code, at which point the browser did exactly what it was told — it treated the example as a real tag and swallowed half the article. No error, no warning. Just a page that quietly ended mid-sentence. One pass through an HTML encoder fixed it, and the lesson stuck: entities aren't trivia, they're the difference between showing code and running it.

By the end of this guide you'll know the five entities worth memorizing, how to write any character numerically when there's no name for it, how to diagnose the classic double-encoding bug, and where entities fit in your security story.

What is an HTML entity?

An entity has three parts: an ampersand, a name or number, and a semicolon. < is the named entity for < — lt for "less than." When the parser meets it, it renders the character and moves on, never mistaking it for the start of a tag.

The HTML spec defines over two thousand named entities, from © (©) to genuinely obscure mathematical symbols. That number scares people into thinking there's a lot to learn. There isn't — because modern pages are UTF-8, you can type ©, é, or 中 directly into your HTML and it just works. Entities are only required for the characters that collide with HTML syntax itself.

The only five entities you must know

That's the whole required reading. Notice the apostrophe uses a numeric code rather than the name ' — that name is valid in HTML5, but it wasn't in HTML4, and some older tooling still chokes on it. ' works everywhere, so it's the safer habit. (You were going to ask about   — the non-breaking space. It's the most common entity in the wild, but it's a layout tool, not an escaping requirement.)

Named, decimal, hex: three spellings of one character

Every character can be written by its Unicode code point, no name required. The copyright sign is code point 169, so all three of these render ©:

&copy;    <!-- named -->
&#169;    <!-- decimal -->
&#xA9;    <!-- hexadecimal -->

This is why you never need to memorize the long tail of named entities: if a character has no name, or you can't remember it, the numeric form always works. The hex variant is handy when you're already looking at a character's code point in a Unicode table — and if hex itself is unfamiliar, our hexadecimal guide covers it in ten minutes.

The double-encoding bug (you'll meet it eventually)

Sooner or later a page will show your users literal text like & or Tom & Jerry. That's double encoding: content that was already encoded got encoded again, so the & in & became &. It usually happens when two layers of a system — say, a CMS and a template engine — each helpfully encode the same string.

Diagnosing it is quick. Paste the broken text into an HTML decoder and decode once. If it comes out right, you had exactly one extra layer; find the code path that encodes already-encoded data and make encoding happen exactly once, at output time. The rule that prevents the whole class of bug: store raw text, encode at the moment you render it — never before.

Entities are a security control, not just a display fix

Everything above treats entities as cosmetic. They're also load-bearing: encoding untrusted input before rendering it is one of the primary defenses against cross-site scripting. If a user submits <script> and you encode it to <script>, the browser displays the text instead of executing it. That single transformation is the difference between showing a comment and running an attacker's code in every visitor's session.

One honest caveat: entity encoding protects HTML element content. Attributes, URLs, and inline JavaScript each have their own escaping rules, and using the wrong one for the context is how encoded-but-still-vulnerable pages happen. Your framework's templating engine almost certainly does context-aware escaping for you — the entities knowledge is for the moments you step outside it.

Encode and decode without thinking

These run entirely in your browser, nothing uploaded:

• HTML Encoder — turn <, >, &, and quotes into safe entities for code samples and dynamic content.
• HTML Decoder — reverse it, including one-layer-at-a-time decoding for double-encoding forensics.
• HTML Viewer — preview markup safely to confirm what actually renders.
• URL Encoder — the sibling escaping scheme for URLs; different characters, same idea.

Conclusion

HTML entities boil down to one rule and five codes: encode text at render time, and know <, >, &, ", and ' on sight. Numeric forms cover every other character, double-encoding means one layer too many, and the same mechanism that fixes your broken code samples is quietly protecting your users from injected scripts. Not bad for a handful of ampersands and semicolons.