HTML Entity Guide: Encode and Decode Special Characters Correctly
HTML uses certain characters for its own structure. The less-than sign opens a tag, the greater-than sign closes one, and the ampersand introduces an entity. When those characters appear as content, for example in the sentence 5 < 10, the browser may misread them as markup rather than text. Encoding replaces such characters with entity references that the browser displays as the original character without treating it as structure. Encoding is what lets a page show code, mathematics and ordinary punctuation safely.
The HTML Entity Encoder and Decoder tool converts in both directions. Encoding turns < into <, > into >, & into &, and a double quote into ". Decoding reverses the process, turning entities back into characters. Entities come in two families. Named entities use a word, such as © for the copyright sign, and are readable but limited to characters that have names. Numeric entities use a code point, such as © for the same copyright sign, and can represent any character, including ones with no named form. Both families end with a semicolon, and omitting it is a common source of display errors.
Encoding matters most in three places. The first is text content, where a stray less-than sign can swallow the rest of a paragraph into a phantom tag. The second is attribute values, where a double quote inside a quoted attribute ends the attribute early and corrupts the markup. The third is code samples and documentation, where the whole point is to display markup as text rather than have the browser interpret it. In each place, encoding is not decoration; it is what makes the intended characters appear at all.
A worked example you can follow
Take the sentence: Tom & Jerry cost < $5 > $3? No, it reads oddly, so use a cleaner sample: A & B < C. Encoding it character by character gives: A, space, &, space, B, space, <, space, C. The original has 9 characters including spaces, and the encoded form has 17 characters: A (1), space (1), & (5), space (1), B (1), space (1), < (4), space (1), C (1), which sums to 1 plus 1 plus 5 plus 1 plus 1 plus 1 plus 4 plus 1 plus 1, equal to 17. The encoded form is longer because each special character expands into a multi-character entity, and that expansion is normal.
Now decode the encoded form and verify the round trip: decoding & gives &, decoding < gives <, and the result is the original A & B < C, 9 characters again. A round trip that does not return the original signals a problem, most often double-encoding. Double-encoding happens when already-encoded text is encoded again: & becomes &, which displays literally as & instead of &. Counting the round trip catches it, because the decoded result differs from the starting text by exactly the extra encoding layer.
A second example shows numeric entities. The copyright sign has code point 169, so its numeric entity is ©, which is 6 characters: &, #, 1, 6, 9 and semicolon. Its named form © is also 6 characters. Either displays the same sign, and the choice between them is usually readability: named forms are easier for humans to recognise, numeric forms cover characters without names. The Remove HTML Tags tool strips markup entirely when that is wanted instead, and the URL Encoder Decoder tool handles the different encoding used inside web addresses.
Common mistakes to avoid
The first mistake is double-encoding, which displays entity text literally instead of the intended character. The second is encoding only some special characters, leaving an ampersand that starts an accidental entity. The third is forgetting attribute values, where a quote can break markup even when the visible text is fine. The fourth is using entities for characters that need no encoding, which bloats markup without benefit. The fifth is assuming encoding fixes broken markup: encoding displays characters safely, but it does not repair unbalanced tags or invalid structure.
For background on keeping markup valid, see HTML Formatter Guide. Encode what the browser would otherwise mistake for structure, decode to check the round trip, and let ordinary characters stay ordinary.
Entities in real documents
Entities appear in more contexts than beginners expect, and each context has its own rule. Inside ordinary text, the three characters that must always be encoded are the less-than sign, the greater-than sign in some edge cases, and the ampersand, because those are the characters the parser treats as structural. Inside attribute values delimited by double quotes, the double quote must also be encoded, and inside values delimited by single quotes, the single quote needs encoding instead. Inside a script block, the rules change again: a script is raw text, not parsed markup, so entities inside it are not decoded as entities at all, and encoding there produces literal entity text in the code rather than the intended character. Knowing which context you are in is the difference between encoding that helps and encoding that corrupts.
Character references also solve a practical problem with characters that are hard to type or invisible. A non-breaking space, written as , keeps two words on the same line, which matters for phrases like 100 km where a line break between the number and the unit would look wrong. An em dash, an arrow, or a mathematical symbol can be written as an entity when the author's keyboard or editor makes the literal character awkward. Modern practice often prefers typing the literal character directly with a UTF-8 document encoding, which is cleaner and shorter, but entities remain the reliable fallback when the encoding is uncertain or the character must survive transport through systems that mangle non-ASCII text.
A final caution concerns user-supplied content. Any system that displays text written by users, such as comments, forum posts or form submissions, must encode that text before inserting it into a page. Without encoding, a user who writes a less-than sign followed by script can inject markup into the page, a vulnerability known as cross-site scripting. Encoding user content is therefore not just a display concern but a security control, and it is one of the cheapest and most effective controls a web application has. Frameworks usually encode by default; custom code must do it deliberately, every time, without exception.