HTML Entities Cheat Sheet

HTML reserves a handful of characters for its own syntax, so writing them literally can break a page or open a security hole. This cheat sheet lists the HTML entities and special character codes you actually need: the five escape characters first, then a typography table, then the rules for when each form is required.

Why escaping matters

The characters < > & and " are control characters in HTML markup. A bare < starts a tag, so writing "a < b" in your source makes the browser hunt for a tag named "b". Worse, inserting user text into a page without escaping lets an attacker inject real markup: a comment containing <script>alert(1)</script> runs as code. Converting those characters to HTML escape characters — <, >, &, " — turns executable markup back into inert text.

The 5 must-know entities

Typography and symbols cheat sheet

Dashes, quotes and spaces

A non-breaking space keeps two words on the same line (write 10 km so "10" never dangles alone) and is not collapsed like a run of normal spaces.

Arrows and math

Legal and currency

Named vs numeric entities

Named entities are readable (— says what it is), but HTML defines only a fixed set of them — just over two thousand names. Numeric references cover every Unicode code point, so characters with no name — emoji, rare symbols, most non-Latin letters — exist only in decimal or hex form: a snowman is ☃ or ☃, nothing else. All three forms decode identically in every modern browser, and the hex letters are case-insensitive. One real caveat: ' was missing from HTML 4 (it came from XML) and only became standard with HTML5, so ' remains the safest apostrophe for very old parsers. In practice, pages served as UTF-8 can include almost any character literally; entities are mandatory only for the markup-significant five.

Where entities are required

Attribute values

Inside a double-quoted attribute, a literal double quote ends the value early: <a title="Say &quot;hi&quot;"> is correct, while an unescaped inner quote truncates the title and leaves the dangling text to be parsed as new attributes. The ampersand must be escaped here too, because attribute values are entity-decoded before use.

Script and style pitfalls

<script> and <style> are raw-text elements: the parser does not decode entities inside them. Writing < in a script gives the JavaScript engine the four characters "&", "l", "t", ";" — not a less-than sign — so never entity-encode code; instead avoid literal closing tags like </script> inside strings. The reverse trap is assuming entities protect user input placed inside a script block: they do not, because no decoding happens there.

Common mistakes

• Bare & in URLs. In HTML source, a query string like ?a=1&copy=2 can be read as containing the entity &copy — some legacy named entities are recognized even without the trailing semicolon. Always write URLs as ?a=1&copy=2 in markup.
• Missing semicolons. Write the full form & every time; browsers tolerate a few semicolon-less names, but the set differs between text and attributes and is a classic source of inconsistent rendering.
• Double-escaping in CMSs. If content was already escaped and gets escaped again on save or render, visitors see < printed as the literal text "<" instead of a rendered character. Escape once, at the boundary where text becomes HTML — and store raw text, not encoded text, in the database.
• Escaping what is already safe UTF-8. Encoding every accented letter as an entity bloats pages and makes source unreadable; declare <meta charset="utf-8"> and only escape the characters that genuinely need it.

Try it: paste any messy string — markup snippets, curly quotes, symbols — into the HTML Entities Encoder / Decoder and convert it to named or numeric entities, or decode an escaped string back to readable text. Everything runs in your browser; nothing is uploaded.