How to use this HTML Entities Encoder / Decoder
Paste your text, markup, or encoded entity string into the input box. Click
Encode HTML Entities to convert special characters into safe entity codes,
or click Decode HTML Entities to convert existing entity codes back into
readable text.
- Paste plain text, HTML, or entity-encoded text into the input field.
- Choose whether you want to encode or decode.
- Review the transformed result in the output area.
- Copy the output for your editor, template, CMS, or code sample.
This tool is ideal for quick browser-based transformations when you need to display markup
safely, prepare documentation, or inspect entity-encoded content.
Example encoded output
Example decoded output
Escaping is context-dependent — that is the whole point
The one idea to take away from this page: the correct way to escape an untrusted string
depends entirely on where it is about to land. HTML text, an HTML
attribute, a URL, the inside of a <script> block, and a CSS value each
have different rules, and a string that is perfectly safe in one is a cross-site scripting
(XSS) hole in another.
HTML-entity encoding — turning < into < and friends — is
the right defence in exactly two of those contexts: HTML text and HTML attribute values.
Everywhere else it ranges from useless to actively dangerous. Reach for entities when you
are placing untrusted data into visible markup; reach for a different encoder when the data
is going somewhere else. The rest of this guide is really just that principle applied to
each context in turn.
The five characters, and why order and ' matter
HTML text really only needs five escapes: & for &,
< for <, > for >,
" for ", and ' for '.
Two details trip people up. First, when you escape by hand you must replace
& first — otherwise the ampersands you introduce while
encoding the other four characters get double-escaped into &lt; and so
on.
Second, the single quote is written as the numeric reference ' rather
than the named '. The named form ' was only
added in HTML5 and XML; it is not valid in HTML4, so it can render
literally in older or quirks-mode contexts. Numeric references sidestep this entirely: they
work for any code point and depend on no named-entity list, which is why
' (or the hex form ') is the universally safe way
to write an apostrophe.
Text context vs attribute context
Inside element text, escaping < and & is enough to stop an
attacker from injecting a tag — there is no way to start a new element without a
<. Attribute values are different, and assuming the text rules cover them is
a common way to ship an XSS bug.
Inside a double-quoted attribute, an unescaped " closes the attribute early and
lets an attacker append their own, for example an
onmouseover= handler — no < required. A single-quoted attribute
has the same problem with ', and an unquoted attribute breaks on a
space and many other characters, which is why unquoted attributes with dynamic values are
best avoided outright. The practical rule: for attributes, escape the quote characters
(" and ') in addition to < and
&, and always quote your attributes.
Escaping is not the same as sanitizing
These two are constantly confused, and the difference decides which one you need.
Escaping makes data render as inert text: after escaping,
<b>hi</b> shows up on the page as the literal characters
<b>hi</b>, not as bold text. Sanitizing keeps
some markup while removing the dangerous parts — it might allow <b>
and strip <script> and onclick attributes.
So if you want to accept user-submitted HTML and actually render it — comments with bold and
links, a rich-text field — entity escaping is the wrong tool; you need a real sanitizer such
as DOMPurify. And the reverse trap is just as common: escape content that was meant to be
genuine markup and your tags appear literally as <b> instead of
rendering. Escape when you want text; sanitize when you want a safe subset of HTML.
Where HTML entities are the wrong tool — and double-escaping
Relying on entity escaping outside HTML markup is a classic XSS trap, because each context
wants its own encoding. Inside a <script> block you need JavaScript or
JSON string escaping, not HTML entities — the parser reads script content before it would
ever decode <. Inside a URL or an href you need
percent-encoding. Inside a <style> block or a CSS value you need CSS
escaping. Inside an HTML comment, none of them help. Right escaping means matching the
encoding to the context the data lands in.
A related symptom is double-escaping: run an escaper over already-escaped text and
& becomes &amp;, which renders visibly on the page
as &. The usual cause is an auto-escaping template engine plus a manual
escape doing the same job twice. If you see stray & or literal entity
codes in rendered output, look for two layers escaping the same string and remove one.
Frequently Asked Questions
Which characters must I escape in HTML?
In element text, escaping & and < is enough to prevent
tag injection (> is commonly escaped too). Inside an attribute value you
must also escape the quote characters — " as " and
' as ' — because an unescaped quote can close the
attribute early and let an attacker add their own.
Is HTML escaping the same as sanitizing?
No. Escaping turns data into inert text, so <b> shows up literally
rather than rendering. Sanitizing keeps a safe subset of markup while stripping the
dangerous parts — allowing <b> but removing <script>
and onclick. If you want to accept and render user HTML, use a sanitizer
like DOMPurify, not entity escaping.
Why use ' instead of '?
' was only introduced in HTML5 and XML and is not valid in HTML4,
so it can render literally in older or quirks-mode contexts. The numeric reference
' works for every code point and needs no named-entity list, which
makes it the universally safe way to escape a single quote.
Do I escape the same way inside an attribute, a script, and a URL?
No — escaping is context-dependent. HTML entities are correct only for HTML text and
attribute values. Inside a <script> block you need JavaScript or JSON
string escaping; inside a URL you need percent-encoding; inside CSS you need CSS
escaping. Using HTML entities in those places does not protect you.
Why do I see &amp; or literal entities on my page?
That is double-escaping: something escaped text that was already escaped, so
& became &amp; and renders as
&. It usually happens when an auto-escaping template engine and a
manual escape both run on the same value. Remove one of the two layers.
Does HTML escaping prevent XSS?
Only in the right context. Correct entity escaping stops injection when untrusted data
is placed in HTML text or a quoted attribute. It does nothing inside a
<script> block, a URL, or a CSS value, each of which needs its own
encoding. Escaping is necessary but must match where the data is used.