HTML Entities, and the Five Characters That Actually Need One

An HTML entity is a way of writing a character using only plain ASCII, so the browser renders that character instead of reading it as markup. & produces an ampersand, < produces a less-than sign, — produces an em dash. On a UTF-8 page — which is every page now — only five characters ever need it, and only two of them need it everywhere. Accents, arrows, currency symbols and emoji you can type directly into the file, and the entities you see for them in old tutorials are left over from an era when you could not.

The three ways to write the same character

Every entity is an entity reference: an ampersand, a name or a number, and a semicolon. There are three forms, and browsers treat them as identical.

• Named — &,  , ©. Readable, but only works for characters somebody bothered to name. The HTML standard's list of names is fixed and will not be extended.
• Decimal — &. The Unicode code point in base 10.
• Hexadecimal — &. The same code point in base 16, which is how Unicode code points are written everywhere else, so U+2014 becomes — with no arithmetic.

All three of those ampersand forms produce the same character. Numeric references exist for anything Unicode can express; named ones only for the shortlist, which is why escapers fall back to numbers. The encoder here keeps a deliberately short list — around seventy names that old parsers and mail clients reliably know — and writes everything else as a number.

Do you need the closing semicolon?

HTML5 decodes roughly a hundred older named references even without the closing semicolon, for compatibility with pages written in 1998. So &copy in body text renders as ©, whether you meant it to or not. This is a trap, not a feature: XML, SVG and RSS parsers reject the same thing outright, and XML only defines five named entities at all — amp, lt, gt, quot and apos. Write the semicolon.

Which characters do you actually have to escape?

Five, and only because the parser would otherwise read them as something other than text.

• & — always. It is what starts an entity reference, so an unescaped one followed by letters can be swallowed.
• < — always in text content. It is what starts a tag.
• > — by convention rather than strict necessity. It costs four characters and removes a category of edge case.
• " and ' — inside attribute values, whichever one you used as the quote. Escaping both means never having to check which.

The ampersand case is the one people argue about. AT&T renders fine, because &T is not a reference. Salt & Pepper is fine too. But a query string like ?page=2&copy=full contains &copy, and in visible text that becomes ?page=2©=full. Inside an attribute value HTML5 has a special rule that saves you — a name without a semicolon followed by = or a letter or digit is left alone — which is exactly the kind of exception you do not want to be relying on. Escape the ampersand and stop thinking about it.

Doing that by eye over a block of text is slow and easy to get half right. An escaper with a minimal mode converts those five and leaves everything else as real characters, which is the correct output for a UTF-8 page and keeps the source readable.

What you can stop escaping

If your document declares <meta charset="utf-8"> and is actually saved as UTF-8, type the character. An em dash, a Turkish ı, a ₹, a 🙂 — all of them are fine as literal text, and all of them are shorter, more readable and less error-prone than — and friends.

Entities are still the better choice for characters that are invisible or ambiguous in source, because nobody can review what they cannot see:

•   — a non-breaking space, U+00A0. It looks identical to a normal space in your editor and does not behave like one.
• ­ — a soft hyphen, which appears only if the word breaks at that point.
• ​, the zero-width space, and the joiner and non-joiner next to it — genuinely invisible, so the next person will delete them by accident.

The non-breaking space is worth knowing properly. Regular spaces collapse: ten of them in a row render as one. A non-breaking space does not collapse, and does not allow a line break. That is why 5 kg never ends up with the 5 on one line and the kg on the next, and it is the correct fix for a number split from its unit. Writing one on purpose is the easy case. Finding the ones somebody else left in your data is the harder one, and a different job.

Why does my page show & instead of &?

Because something escaped text that was already escaped. The ampersand in & got escaped a second time into &, and the browser faithfully decodes one layer and prints the rest.

It is a pipeline problem, not a typo. A form escapes input on save, the template escapes it again on render, and the second pass cannot tell that the first one happened. The damage compounds predictably, so decoding the string repeatedly until it stops changing tells you how many layers are there. Then remove the escape step that should not be running. Escaping once, at the point of output, is the only arrangement that does not eventually produce this.

Entities, URL encoding and JSON escaping: which goes where?

Three different escaping systems, three different alphabets, applied at three different moments. A space is   in HTML, %20 in a URL and \u0020 in JSON, and using one where another belongs produces text that looks almost right and is broken.

The overlap that causes the most damage is a link. The href is HTML, so it gets entity-escaped; the thing inside it is a URL, so its own reserved characters need percent-encoding first. Both, in that order. If you have ever watched a link break the moment someone put a space or a plus sign in a parameter, the rules behind percent-encoding are the half of the answer that entities do not cover.

JSON is its own world again. HTML entities mean nothing inside a JSON string — they are just characters — and JSON's \u escapes mean nothing to an HTML parser. When a response arrives as one unbroken line of escaped sequences, formatting it before you try to read it will tell you in seconds whether the problem is the data or the encoding.

Is escaping enough to stop XSS?

In HTML text and in quoted attribute values, escaping those five is what stops injected markup from being markup. Outside those two places it buys you much less than it looks like it does. Escaping makes markup display as text; it does not remove anything, and it is correct only for the context you are writing into. Four places where it is not enough:

• Unquoted attributes. <div class=VALUE> ends at the first space, so escaping quotes buys nothing. Quote your attributes.
• Inside <script>. That is a JavaScript string context. Entity references are not decoded there at all, and the literal sequence </script> inside a string still ends the block.
• Inside a URL attribute. javascript:alert(1) contains nothing an escaper would touch, so escaping it leaves a working link. And entities in an href are decoded before the URL is parsed, so a filter looking for the literal text javascript: walks straight past javascript: — j is a j. Check the scheme instead.
• Inside CSS. Different escaping rules again.

And if you want to keep some tags and drop others — allow <b>, reject <script> — that is sanitising, and it needs a real parser with an allowlist. Escaping is all-or-nothing by design.

Why did my emoji come out as two broken entities?

Characters above U+FFFF — emoji, rarer CJK, most historic scripts — are stored in JavaScript as two code units. An escaper that walks a string one index at a time emits two references like ��, and no parser can put those back together; HTML turns each half into a replacement character. A correct escaper iterates by code point, so a grinning face becomes the single reference 😀. If you have ever seen a row of black diamonds where an emoji should be, this is usually why.

Numeric references between € and Ÿ misbehave in a different way. HTML parsers deliberately do not render those as the Unicode control characters they name; they map them to the Windows-1252 characters authors meant in the 1990s, so — comes out as an em dash. Correct per the standard, entirely unobvious, and one more reason to type the character rather than the number.

Last updated September 19, 2026