HTML Entities Explained: The Complete Guide to Encoding and Decoding Special Characters
Every web page you have ever opened is built from characters, and some of those characters are troublemakers. The less-than sign starts a tag. The ampersand starts a reference. The quotation mark ends an attribute value. When the text you actually want to display contains one of these characters, the browser cannot guess whether you meant the symbol or the syntax — so HTML gives you a safe way to write it: the character reference, better known as the HTML entity. GlyphCode exists to make working with those references effortless. Paste in plain text and get clean, standards-compliant entities in named, decimal or hexadecimal form. Paste in encoded markup and get your readable text back. No uploads, no waiting, no guesswork.
What exactly is an HTML entity?
An HTML entity is a short sequence that begins with an ampersand (&) and ends with a semicolon, and stands in for a single character. The most famous example is <, which displays as the less-than sign. When a browser parses a document and meets <, it knows the author wanted the symbol itself, not the start of a tag, and renders it as text. Entities solve three separate problems at once. First, they disambiguate reserved characters that have a structural meaning in HTML. Second, they represent characters that are difficult or impossible to type on an ordinary keyboard, such as the em dash, the euro sign or the infinity symbol. Third, they represent invisible or easily confused characters — the non-breaking space being the classic example — so that the intent of the author survives copy-pasting, minification and editors that would otherwise normalise the whitespace away.
Named, decimal and hex: three spellings for the same character
HTML offers three ways to write a reference, and GlyphCode converts between all of them. A named entity uses a human-readable word defined by the HTML specification: © for ©, — for —, … for …. Named entities are the easiest to read in source code and the easiest to remember, but they only exist for a defined list of characters. A decimal entity uses the character's Unicode code point written in base ten: © is ©. A hexadecimal entity writes the same number in base sixteen, prefixed with an x: ©. Numeric references work for absolutely every character in Unicode — including emoji and rare scripts that never received a name — which is why GlyphCode falls back to decimal form whenever you encode a character that has no name. All three spellings render identically in every browser, so the choice is purely about readability and tooling: named for hand-written content, numeric for generated output.
The five characters you must never leave raw
Most characters can be pasted into an HTML document as-is, especially now that UTF-8 encoding is universal. Five characters, however, should always be encoded when they are meant as text. The ampersand begins every reference, so a raw ampersand in a URL or a sentence like "Fish & Chips" can accidentally form a broken entity. The less-than and greater-than signs delimit tags; a raw less-than sign in an expression such as "5 < 6" may swallow the rest of the sentence as a bogus tag in lenient parsers. The double quotation mark terminates attribute values, so a quote inside an attribute must become ". The apostrophe plays the same role for single-quoted attributes and is written ' in XML and XHTML contexts. GlyphCode's default scope — "Special chars only" — encodes exactly these five and leaves everything else untouched, which makes it perfect for sanitising a snippet before dropping it into a template.
When should you encode more than the basics?
The "Special + non-ASCII" scope goes further and converts every character outside the plain ASCII range into a reference. That is the right choice when your output travels through systems with unreliable encoding: plain-text email pipelines, legacy content management systems, RSS and Atom feeds assembled by string concatenation, PDF generators with limited font support, or databases whose charset you do not control. Encoded output is pure ASCII, so it survives any transport without mojibake — those garbled sequences like é that appear when UTF-8 text is read as Latin-1. The "Every character" scope is the extreme option: it encodes letters and digits too, producing output that is useful for obfuscation demos, for embedding text inside layers of nested markup, and for testing how parsers handle fully escaped documents. It is rarely needed in production, but developers reach for it surprisingly often when debugging escaping bugs in template engines.
Decoding: recovering readable text from escaped markup
Decoding is the reverse journey, and it is just as common a task. You copy a headline out of a page's source and it arrives littered with ’ and —. A data export escapes every apostrophe. An API returns double-encoded strings that display literally as "&" on your page. GlyphCode's decoder handles named, decimal and hexadecimal references in a single pass and reports how many entities it replaced. Just as importantly, it warns you about entity names it does not recognise: a typo like &coppy; is left untouched and flagged, rather than being silently deleted, so you can fix the source instead of losing content. Note that decoding is deliberately one level deep — decoding twice is how double-encoding bugs are born, and if you genuinely need a second pass, the "Use output as input" button makes that an explicit, visible step.
The symbol picker: a faster way to find the right reference
Half the battle with entities is remembering that the character you want exists at all. The clickable symbol grid above gathers the forty symbols developers and writers reach for most — currency signs, dashes, quotes, mathematical operators, arrows, card suits and more. Clicking a symbol inserts the character into your input, and the detail strip shows all of its forms side by side: the named entity, the decimal entity, the hex entity and the Unicode code point, each one click-to-copy. It doubles as a cheat sheet you can actually use, and because choosing a symbol in Encode mode immediately shows you its encoded form in the output pane, it is also the fastest way to answer the question "how do I write this character in HTML?" without leaving the page.
Why the live rendered preview matters
Encoded text is hard to proofread. A paragraph full of numeric references hides its own typos, and a misplaced semicolon can change a sentence's meaning or break its layout. The live preview panel renders your output exactly as a browser would display it, updating on every keystroke. If an entity is malformed, the preview shows the raw code instead of the glyph — a visual alarm that something is wrong before you ship it. If you encoded with the non-ASCII scope, the preview proves at a glance that your accented letters, arrows and currency signs survived the conversion. Proofreading the rendered result rather than the code is a small habit that prevents a large class of embarrassing publishing mistakes, from newsletters that greet subscribers with " " to documentation pages that print entity codes instead of symbols.
Common mistakes and how to avoid them
A few entity errors appear again and again. The first is forgetting the trailing semicolon: most browsers forgive it for legacy named entities in text, but not inside attribute values, and not for numeric references — always include it. The second is double-encoding: escaping text that is already escaped, which produces visible "&" artefacts; decode once, check the preview, and only then encode. The third is reaching for as a layout tool to add spacing — use CSS margins instead, and reserve the non-breaking space for its real job of keeping two words on the same line. The fourth is assuming entities work everywhere plain text goes: they do not decode inside <script> or <style> blocks, in plain-text emails, or in most non-HTML formats, so encode for the context you are actually publishing into. Finally, remember that entities are a display mechanism, not a security mechanism: encoding user input helps prevent markup injection, but proper output escaping must happen in your application code for every context — HTML, attributes, URLs and JavaScript each have their own rules.
A short history, from HTML 2 to the HTML5 living standard
Character references are as old as HTML itself. The earliest specifications defined a small set based on the Latin-1 repertoire, which is why the oldest names describe accented letters. HTML 4 expanded the list with Greek letters, mathematical symbols and geometric shapes borrowed from the SGML entity sets, bringing the total to 252. HTML5 unified everything into a single table of 2,231 named references, added the rule that every reference is defined by its Unicode code point, and — quietly revolutionary — made the named list case-sensitive in precisely documented ways. Today the living standard keeps that list stable, and every browser ships the same table, which is why a tool like GlyphCode can promise that what you encode here will render the same everywhere. Understanding entities is therefore not nostalgia: it is a permanent, load-bearing part of how the web represents text, and fluency with them pays off every time you touch markup, templates, feeds or generated content.