HTML Entity Encoder & Decoder
Turn <, > and & into
entities so markup shows up as text, or decode entities back into the
characters they stand for.
How to use it
- Pick Encode to make markup safe to show, or Decode to read entities back as characters.
- Paste into the left box. The result updates as you type.
- Copy the result, or send it back as input to check that it round-trips.
Why HTML has to be escaped
A browser reading a page cannot tell your content apart from the
markup around it. It only knows that < starts a tag and
& starts an entity. So the moment a visitor's name, a
comment or a code sample contains one of those characters, the browser
reads it as an instruction instead of as text.
Two things go wrong. The harmless one: your page breaks, a stray
<b swallows the rest of the paragraph, or
Tom & Jerry disappears into a half-formed entity. The
serious one: someone types <script> into a comment
box and the site runs it for every visitor who reads that page. That is
cross-site scripting, and escaping is the first line of defence
against it.
Only three characters strictly must be escaped in ordinary text:
&, < and >. Inside an
attribute the quote characters matter too, because a stray
" ends the attribute early and everything after it becomes
new markup. That is why the quotes option here is on by default.
Frequently asked questions
Which characters actually need escaping?
In ordinary page text, three: & then < then >. The ampersand must be done first, otherwise you escape the ampersands you just created. Inside an attribute value you also need the quote character, because a stray quote ends the attribute early and everything after it is read as markup. This page does all of them by default.
Why does it produce ' instead of ' for an apostrophe?
Because ' is an XML entity that was never part of HTML 4, and old versions of Internet Explorer print it as literal text instead of an apostrophe. The numeric form ' means the same thing and has worked everywhere for thirty years, so it is the safer output.
Do I need to encode accented or Indian-language characters?
Not if your page is UTF-8, which every modern page is - a Telugu letter or a rupee sign can sit in the source as itself. The option to encode them as numbers is there for the cases where it still matters: a legacy system with an unknown encoding, an email template, or a database column you cannot trust. The page renders identically either way.
Is escaping HTML enough to stop cross-site scripting?
It is necessary, not sufficient. Escaping these characters makes text safe in ordinary page content, which is the common case. Text going into a javascript: URL, an inline event handler, a style block or a URL parameter needs the escaping that belongs to that context instead. Escape for the place the text lands in, not out of habit.
What happens to an entity this tool does not recognise?
It is left exactly as it was found, and the page tells you how many were left. HTML has well over a thousand named entities; this tool knows the ones in real use plus every numeric form, decimal and hexadecimal. Silently deleting something it did not understand would be worse than leaving it visible.
Is my text sent anywhere?
No. Everything happens in JavaScript inside your own browser. Nothing is uploaded and nothing is saved - close the tab and it is gone.