HTML Encoder / Decoder
Encode text to HTML entities or decode HTML entities back to text.
How to use HTML Encoder / Decoder
- 1
Enter your text or HTML
Paste plain text you want to escape, or HTML entities you want to convert back, into the input box.
- 2
Choose encode or decode
Click Encode to HTML Entities to convert characters like < > & into safe entities, or Decode HTML Entities to turn entities back into readable characters.
- 3
Review the output
Check the converted result in the output box, and use Swap Input/Output to chain a reverse conversion if needed.
- 4
Copy the result
Press Copy Output to grab the encoded or decoded text, or Clear Both to reset the fields.
HTML Encoding: Escaping Special Characters Safely
What HTML encoding means
HTML encoding, also called HTML escaping, converts characters that have special meaning in HTML into character references so a browser displays them as literal text instead of interpreting them as markup. The browser reads a raw < as the start of a tag, so to show an actual less-than sign on the page you must write the reference < instead. Encoding is the safe translation between what you want shown and what the browser would otherwise execute.
There are only a handful of characters that genuinely need escaping in everyday HTML, but getting them right is the difference between a page that renders correctly and one that breaks or becomes vulnerable. The references come in two flavors: named entities like <, and numeric references like < or <, all of which produce the same visible character.
The core characters and their entities
Five characters cover almost every escaping need. The ampersand & becomes & and must come first in any manual conversion, because it begins every entity. The less-than sign < becomes < and the greater-than sign > becomes >, since these delimit tags. The double quote " becomes " and the single quote or apostrophe ' becomes ' (or the named ' in HTML5), which matter inside attribute values.
The ampersand-first rule prevents a subtle bug. If you replaced < with < and only afterward escaped ampersands, you would turn your freshly written < into &lt; and show the literal text "<" on the page. Always encode & before the others. This tool applies the conversions in the correct order automatically, so you never hit that trap.
Worked example: displaying a code snippet
Imagine you want a page to literally show the text <a href="x">Tom & Jerry</a> rather than render a link. Each special character is replaced by its reference. The opening angle bracket becomes <, the closing one becomes >, the double quotes around the attribute become ", and the ampersand between the names becomes &.
The encoded result is <a href="x">Tom & Jerry</a>. Pasted into an HTML file, the browser prints the original source code visibly on screen, exactly as a tutorial or documentation page would show example markup, instead of turning it into a working anchor element.
Why encoding prevents XSS
Cross-site scripting (XSS) is an attack where an attacker injects HTML or JavaScript into a page through a field that is later displayed to other users, such as a comment, username, or search term. If a site inserts that untrusted text into the page without escaping, a payload like a script tag executes in the victim's browser with the site's privileges, enabling session theft and worse.
Encoding neutralizes the attack at its root. When the dangerous characters are escaped, an injected <script>alert(1)</script> is stored and rendered as harmless visible text — <script>alert(1)</script> — rather than as an executable element. The single most reliable defense against this class of vulnerability is to HTML-encode every piece of untrusted data at the exact point where it is written into the page.
Element content versus attribute context
Where you place data changes which characters are dangerous, and a single escaping rule is not enough for every spot. Inside element content — the text between an opening and closing tag — the critical characters are <, >, and &. Inside an attribute value, the quote character that delimits the attribute is the one that lets an attacker escape the value, so " and ' must be encoded there in addition to the ampersand.
The most robust habit is to always quote your attributes and to encode the matching quote character along with < > and &. An unquoted attribute is far harder to secure, because then spaces and many other characters can break out of the value. There are also entirely separate contexts — inside a script block, a style block, or a URL attribute — where HTML escaping alone is insufficient and a context-specific encoding is required instead.
Encoding versus decoding, and when to do each
Encoding is the direction you reach for when generating output: take raw text and produce safe markup with the Encode action. Decoding is the reverse, turning entities back into their literal characters with the Decode action, which is useful when you have escaped source — copied from a database, an email, or another tool — and want to read or edit the underlying text.
A practical workflow uses both with the Swap button. You might decode a stored snippet to plain characters, edit it, then re-encode the edited version for safe display, all without retyping. Just remember the golden rule of timing: encode at the moment of output, not at the moment of input, because escaping too early can corrupt data that needs to stay raw in storage.
Common mistakes to avoid
The classic error is double-encoding: running already-escaped text through the encoder again, which turns & into &amp; and shows literal "&" to your users. Encode exactly once, and only at the output boundary. A close cousin is escaping data on the way into your database and again on the way out, producing the same garbled result.
Another frequent mistake is assuming HTML escaping protects every context. It does not protect data placed inside a JavaScript string, a CSS value, or an href that starts with javascript:; those need their own encoding rules. Finally, do not hand-roll a partial escaper that forgets the ampersand or the attribute quotes — the gaps are exactly where bugs and XSS slip through. Let a complete, correctly ordered encoder do the work.
Frequently asked questions
What characters get encoded into HTML entities?
How does encoding help prevent XSS?
Can I convert entities back to normal text?
What is the Swap button for?
Is my input sent to a server?
Related tools
Keep going with these handy tools