Skip to content
ToolBoxGeniehome

HTML Entity Encoder & Decoder

Developer Tools · Added

Turn characters into HTML character references and back again. The default escapes only the five characters HTML actually reserves, which is what a templating engine does and what you almost always want; wider scopes and numeric formats are there for the cases where you need them. A breakdown table shows every character being replaced, in all three notations at once.

Direction

Paste anything. Nothing is sent anywhere — the conversion runs in this tab.

Escapes only & < > " and ' — the five characters that change how HTML parses. This is the right choice for almost every use, and the one a templating library makes for you.

Result

Characters replaced
7
Length
37 → 63

Characters in, characters out

Every character being encoded, in each format
CharacterNamedDecimalHexCode point
<&lt;&#60;&#x3C;U+003C
"&quot;&#34;&#x22;U+0022
>&gt;&#62;&#x3E;U+003E
&&amp;&#38;&#x26;U+0026

Decoding runs once, not repeatedly. That matters more than it sounds: decoding &amp;lt; twice would turn a documented example of an escaped tag into a live one, which is the shape of a great many cross-site scripting bugs. Escaping is also not sanitisation — it makes text safe to display, and does nothing about markup you actually intend to render.

The references worth knowing

CharacterNamedNumericWhat it is
&&amp;&#38;The one that has to be escaped first
<&lt;&#60;Opens a tag
>&gt;&#62;Closes a tag
"&quot;&#34;Ends an attribute value in double quotes
'&apos;&#39;Ends an attribute value in single quotes
 &nbsp;&#160;Non-breaking space
©&copy;&#169;Copyright
®&reg;&#174;Registered trademark
&trade;&#8482;Trademark
°&deg;&#176;Degree
&euro;&#8364;Euro
£&pound;&#163;Pound
¥&yen;&#165;Yen
&ndash;&#8211;En dash, for ranges
&mdash;&#8212;Em dash, for asides
&lsquo;&#8216;Left single quote
&rsquo;&#8217;Right single quote, also the apostrophe
&ldquo;&#8220;Left double quote
&rdquo;&#8221;Right double quote
&hellip;&#8230;Ellipsis
×&times;&#215;Multiplication sign
&rarr;&#8594;Right arrow
&le;&#8804;Less than or equal to
&ge;&#8805;Greater than or equal to

How to use the html entity encoder & decoder

  1. 1Pick a direction — text to entities, or entities back to text.
  2. 2Paste your text or markup. Everything runs in this tab.
  3. 3Choose what to encode. Reserved only is the safe default; add non-ASCII if the output has to survive a system that mangles UTF-8.
  4. 4Choose a format. Named references are readable, numeric ones work everywhere, and hexadecimal matches how code points are written in Unicode charts.
  5. 5Leave invisible characters revealed to catch a non-breaking space or a zero-width joiner that has been pasted in without you noticing.

Examples

Escaping a tag so it displays

Input
<p class="lead">Tom & Jerry</p>
Result
&lt;p class=&quot;lead&quot;&gt;Tom &amp; Jerry&lt;/p&gt;

This is what you paste into a page to show markup rather than run it.

Decoding scraped text

Input
Caf&eacute; &#8212; &pound;5
Result
Café — £5

Named, decimal and hexadecimal references all decode.

An entity that is not one

Input
Salt &pepper; and vinegar
Result
Left exactly as it is, with the sequence reported

Deleting an unknown reference would silently change your text.

Finding an invisible character

Input
A pasted price with a non-breaking space in it
Result
&nbsp; made visible in the output and listed in the table

About the html entity encoder & decoder

Three ways to write the same character

A character reference always starts with an ampersand and ends with a semicolon. In between it is either a name, a decimal code point after a hash, or a hexadecimal code point after a hash and an x. So &eacute;, &#233; and &#xE9; are three spellings of exactly the same character, and a browser treats them identically.

The semicolon is not optional in practice, even though some parsers will forgive its absence for historical reasons. Leaving it off produces markup whose meaning depends on which parser reads it, and this tool always emits it.

The invisible characters worth catching

Text pasted from a word processor, a PDF or a web page frequently carries characters that look like a space and are not: non-breaking spaces, thin spaces, zero-width joiners, and the occasional byte order mark that has survived a file conversion. They break string comparisons, they defeat search, and they are invisible in every editor that does not go looking for them.

Revealing them is on by default here for that reason. A non-breaking space rendered as &nbsp; in the output is immediately obvious, and the breakdown table labels it explicitly rather than showing a blank cell you would scroll straight past.

Where entities still earn their place

Three cases come up repeatedly. Showing code on a page, where the whole point is that the markup must not run. Email templates, where the rendering environment is genuinely unpredictable and the cost of a numeric reference is nothing. And characters that are ambiguous in source — a non-breaking space is worth writing as &nbsp; even in a UTF-8 file, precisely because the alternative is invisible.

Outside those, modern practice is to write the character itself and let the file's encoding carry it. A page full of &eacute; where an é would do is a page that is harder to edit for no benefit, and it usually indicates a pipeline that escaped its data twice.

Frequently asked questions

Which characters actually need escaping?
In body text, only the ampersand and the less-than sign can change how a document parses. Inside an attribute value you also need whichever quote character delimits it. The conventional five — ampersand, less-than, greater-than and both quotes — are escaped together because it is easier to be consistent than to reason about context every time, and that is what this tool's default does.
Do I need to escape é, — or emoji?
Not on a page that declares UTF-8, which is every page written this century. Those characters are perfectly legal in the source and escaping them only makes it harder to read. The wider scopes here exist for the cases that do come up — a legacy template system, an email pipeline that mangles high bytes, a feed consumed by something old — rather than as a recommendation.
Named or numeric?
Named references are easier to read and there are only a few hundred of them; numeric references work for every character Unicode defines and need no lookup table at the far end. If a human will read the source, use named. If the consumer is unknown or old, numeric is the safer bet — and if you are working from a Unicode chart, the hexadecimal form matches the U+ notation you already have.
Why is decoding only done once?
Because repeating it changes meaning. The text &amp;amp;lt; is an escaped example of the string &amp;lt;, which is itself an escaped less-than sign. Decode once and you get the example back. Decode twice and you get a live opening bracket — which is the precise mechanism behind a whole family of cross-site scripting bugs, and why double-decoding is treated as a defect rather than a convenience.
Does escaping make user input safe?
It makes it safe to display as text, which is one part of the problem and not the whole of it. Escaping does nothing for markup you deliberately render, for JavaScript contexts, for attribute values assembled without quotes, or for URLs in href attributes. Use your framework's escaping at the point of output rather than pre-escaping data on the way in, and reach for a sanitiser when you genuinely need to allow some HTML through.
How complete is the name table?
HTML5 defines 2,231 named references, most of them aliases and mathematical symbols that never appear in ordinary markup. This tool carries the practical subset: the reserved characters, Latin-1, typographic punctuation, currency, arrows, common mathematical operators and Greek. Anything outside it still encodes correctly as a numeric reference, and the tool tells you when it has fallen back rather than inventing a name.