How to encode or decode HTML entities
- Paste your text or markup into the box above.
- Choose Encode to escape it, or Decode to turn entities back into characters.
- Enable non-ASCII encoding only if you are targeting a legacy system.
- The result appears immediately below.
- Copy it into your page, template or database field.
What this tool covers
- Escapes the five characters that matter: ampersand, angle brackets and both quote types.
- Decodes every named entity, using the browser's own complete entity table.
- Handles numeric entities in both decimal and hexadecimal form.
- Optional encoding of non-ASCII characters for legacy environments.
- Works in both directions from one box, switched with a single control.
- Runs live in your browser with nothing uploaded.
What escaping actually prevents
HTML has no way to know whether <script> in a piece of text is meant as markup or as characters to display. It assumes markup. That assumption is the root of cross-site scripting: user input containing a script tag gets inserted into a page, the browser sees a real script tag, and it runs.
Escaping removes the ambiguity. Replace the angle brackets with < and > and the browser displays the characters instead of interpreting them. That single transformation is the foundation of output safety on the web.
The five characters that matter
- & →
&: must be first, or it would re-escape the others. - < →
<and > →>: the tag delimiters. - " →
": closes a double-quoted attribute value. - ' →
': closes a single-quoted attribute value.
Both quote characters matter because attribute values may be quoted either way, and escaping only one leaves an injection route open through the other.
Where you need this
Displaying code samples on a page is the everyday case, without escaping, your example markup renders instead of appearing. The same applies to putting user-supplied text into a template, storing markup in a database field that will later be rendered, and writing documentation about HTML.
Decoding is the reverse: reading text that has been escaped somewhere along the way, cleaning up content pulled out of a CMS, or working out what a payload actually contains when it arrives full of &amp; sequences, which, incidentally, means it was escaped more than once.
Escaping is not sanitising
Worth being precise about. Escaping converts markup into text, which is the right answer when you want to display it. Sanitising removes dangerous markup while keeping the safe parts, which is what you need when users are allowed to submit formatted content.
They solve different problems and neither substitutes for the other. If you are building something that accepts rich text from users, escaping alone will show them their own HTML tags as literal text; sanitising is what you want, and it needs a proper library rather than a transformation like this one.
Non-ASCII characters
The option to encode everything above ASCII exists for legacy systems that cannot be trusted with UTF-8. It is rarely needed now and it inflates the output substantially. Every accented character becomes a numeric entity of six or seven characters. Leave it off unless something downstream demands it.
For converting Markdown into safely escaped HTML in one step, the Markdown converter escapes raw HTML as it goes. The HTML formatter tidies markup you are keeping as markup. Nothing is uploaded at any stage.
Escaping in the right place
The rule that prevents most injection bugs is to escape on output, not on input. Store what the user actually typed, and escape it at the moment it is rendered into a page. Escaping on the way into a database seems tidier and causes problems: the same value is then double-escaped if it is rendered through a template that escapes as well, and it is wrong if it later goes somewhere that is not HTML at all, such as an email subject line or a PDF.
Context matters too. HTML escaping is correct inside element content and attribute values; it is not sufficient inside a script block, a style block or a URL, each of which needs its own escaping rules.