HTML Entity Encoder/Decoder
This tool allows you to convert text with special characters to HTML entities and vice versa. HTML entities help display special characters correctly on web pages.
Mode
<
<
Less than sign
>
>
Greater than sign
&
&
Ampersand
"
"
Double quotation mark
'
'
Single quotation mark
©
©
Copyright symbol
®
®
Registered trademark
How to use HTML Entity Encoder/Decoder
- 1
Enter your text
Paste the text or HTML snippet you want to convert into the input box.
- 2
Choose encode or decode
Click Encode to turn special characters into HTML entities, or Decode to turn entities back into characters.
- 3
Get the result
The converted output appears instantly in the result panel.
- 4
Copy the output
Use Copy Result to grab the encoded or decoded text for your project.
A Practical Guide to HTML Entities
What an HTML entity is
An HTML entity, more formally a character reference, is a short code that stands in for a single character in HTML. Every entity begins with an ampersand (&) and ends with a semicolon (;). Entities let you include characters that the browser would otherwise misinterpret as markup, characters that are hard to type, or characters that are not present on your keyboard, all while keeping the source file in plain ASCII.
Entities matter for two distinct reasons. First, a few characters are reserved by HTML itself and must be escaped to display correctly. Second, the vast world of symbols, accented letters, currency marks, arrows, and emoji can be written reliably as references regardless of the file's text encoding. This tool encodes characters into entities and decodes entities back into the characters they represent.
Named versus numeric references
There are two ways to write an entity, and they are interchangeable in what they produce. A named reference uses a human-readable label, such as © for the copyright sign, & for an ampersand, or for a non-breaking space. HTML defines a fixed list of these names, so only characters with an assigned name can be written this way.
A numeric reference uses the character's Unicode code point instead of a name, and it can represent any character at all. The decimal form is an ampersand, a hash, the code point in base 10, and a semicolon — for example ©. The hexadecimal form adds an x after the hash and gives the code point in base 16 — for example ©. All three of ©, ©, and © render the identical © symbol, because 169 in decimal equals A9 in hexadecimal equals the copyright code point.
The five that always need escaping
Most characters are optional to encode, but a small group is effectively mandatory in HTML source. The ampersand & (&) must be escaped because it starts every entity; leave it raw next to a word and the browser may try to parse an entity that is not there. The less-than sign < (<) and greater-than sign > (>) must be escaped in text because they delimit tags. Inside attribute values, the double quote " (") and apostrophe ' (') need escaping so they do not close the attribute early.
Everything else is a convenience. You can write é directly in a UTF-8 file or as é or é — all are valid. The reserved five are different: getting them wrong produces broken markup or, with untrusted input, a cross-site scripting hole, so they are the characters you must never leave unescaped in the wrong place.
Worked example: symbols and accents
Suppose you want a footer to read "© 2026 Café Ünïcode — 100% safe". Several of these characters are not plain ASCII. The copyright sign can be written as © or ©. The é in Café is é or é, and the Ü is Ü or Ü. The em dash — is — or —, and the non-breaking space that keeps "100%" together is .
Encoding the whole string yields something like © 2026 Café Ünïcode — 100% safe, which is guaranteed to display identically no matter how the page's character encoding is configured. Decoding it here reverses the process and gives you back the readable line with the real symbols in place.
Choosing named or numeric
Named entities win on readability. © and — tell a future reader exactly what the character is, which makes source easier to maintain than a wall of numeric codes. The trade-off is coverage: only characters with an assigned name can be written by name, and the list, while large, does not include everything.
Numeric references win on universality and precision. Because they address the Unicode code point directly, they can encode any character in existence, including ones with no name and including emoji. They are also unambiguous, which is handy when you need to be certain about an obscure symbol. A common practice is to use named entities for the familiar handful (©, &, , —) and numeric references for anything exotic.
Emoji and characters beyond the basic range
Emoji and many symbols live high in the Unicode range, above the values a single old-style code unit can hold, but numeric references handle them cleanly because they simply name the code point. The grinning face emoji has code point U+1F600, so it can be written as the decimal reference 😀 or the hexadecimal reference 😀, both of which produce the same glyph.
In practice, saving your file as UTF-8 and pasting the emoji directly is usually simpler and just as correct. Numeric references become valuable when a pipeline cannot be trusted to preserve raw bytes — an email template, a system that flattens to ASCII, or a context where you want the exact code point recorded unambiguously. Either way, the character that appears is determined entirely by its code point.
Decoding garbled entity text
A very common real-world task is cleaning up text that arrives full of visible entity codes. You copy a paragraph from a web page or a database export and instead of normal punctuation you see &, ', ", and ’ scattered through it. That means the text was HTML-encoded somewhere upstream and never decoded for display. Pasting it into the Decode mode here turns those references back into the real &, ', ", and curly apostrophe characters.
Watch for double-encoding, the situation where text was escaped twice and you see sequences like &amp; or &#39;. Here the literal characters &amp; should become & and then &, so the fix is to decode more than once until no entities remain. If a single decode pass still leaves & in your output, run the result through Decode again to strip the second layer.
Common pitfalls
The most frequent mistake is the missing semicolon. An entity is only valid when it is terminated, so © with no semicolon may not render as the copyright sign. A related error is encoding the ampersand last instead of first when escaping by hand, which turns your other entities into literal text like &lt;.
Also remember that entities are an HTML concept, not a security boundary by themselves. Encoding untrusted input into entities is part of preventing broken markup and XSS, but it must be done in the right context and at output time, not relied upon as a cure-all. Finally, do not encode characters that do not need it inside ordinary content — over-encoding makes source harder to read and offers no benefit when the file is already UTF-8.
Frequently asked questions
What are HTML entities and why use them?
Which characters does the encoder convert?
Can I convert entities back into normal characters?
Is this useful for preventing broken HTML or XSS?
Does my text get sent to a server?
Related tools
Keep going with these handy tools