HTML entity encoder

How to use this tool

HTML reserves a handful of characters for its own syntax, and writing them literally causes the browser to misinterpret your content. The critical five are & (starts an entity), < and > (delimit tags), and " and ' (delimit attribute values).

Encoding replaces each with a reference — < for <, & for & — which tells the browser to display the character rather than interpret it. Order matters when encoding by hand: escape the ampersand first, or you'll double-encode the entities you just created.

Why this is a security control, not a formatting one

Escaping output is the primary defence against cross-site scripting. If user-submitted text goes into your page unescaped, a comment containing a script tag becomes executable code running with your site's privileges — able to read cookies, hijack sessions and act as the logged-in user.

Escaping neutralises it entirely: the same input renders as harmless visible text. Modern frameworks escape by default, which is why XSS is rarer than it was — but every framework also has an escape hatch (dangerouslySetInnerHTML in React, v-html in Vue, innerHTML in vanilla JS). Those are where XSS lives today, so treat any use of them as needing justification.

Named versus numeric references

There are two forms. Named references like © and   are readable but limited to a defined list. Numeric references like © or hexadecimal © work for any Unicode character.

In practice, with UTF-8 encoding — which every modern site should declare — you can write most characters like é, — and © directly. Reserve entities for the five reserved characters, and for cases where the literal is invisible or ambiguous in source:   for a non-breaking space is the classic example, since it looks identical to a normal space in your editor.

Decoding, and when you need it

Decoding runs the other way — turning <div> back into readable text. It comes up when an API returns pre-escaped content, when a database stores escaped strings, or when content has been double-encoded somewhere in a pipeline and displays as literal < on the page.

This tool decodes using the browser's own parser, so it handles named and numeric references correctly rather than relying on a lookup table that inevitably misses cases. One caution: never decode untrusted content and then insert it as HTML — that undoes the protection escaping provided in the first place.

Escaping for attributes, not just text

A popular shortcut escapes a string by putting it in a text node and reading back innerHTML. That escapes &, < and >, but the HTML serialiser leaves quotes alone in text, so the output is unsafe as soon as it lands inside an attribute value: an input such as " autofocus onfocus="… closes the attribute and adds an event handler. If you build HTML as strings, in a server template, an email body or a template literal, use an escape function that covers all five characters:

const ESCAPES = {
  '&': '&',
  '<': '&lt;',
  '>': '&gt;',
  '"': '&quot;',
  "'": '&#39;',
};

// One pass, so '&' can never be double-encoded
function escapeHTML(value) {
  return String(value).replace(/[&<>"']/g, ch => ESCAPES[ch]);
}

const name = `" autofocus onfocus="alert(document.cookie)`;

console.log(`<input value="${escapeHTML(name)}">`);
// <input value="&quot; autofocus onfocus=&quot;alert(document.cookie)">

console.log(escapeHTML("Tom & Jerry's <b>"));
// Tom &amp; Jerry&#39;s &lt;b&gt;

In the browser, the better answer is usually not to escape at all. Assign to element.textContent or call setAttribute(), and the value is stored as data and never parsed as markup, so there is no escaping step to forget. Keep a string escaper for the cases where the output really has to be an HTML string.

Escaping also has limits. It protects text and quoted attribute values only; an unquoted attribute can be broken with a plain space. It does nothing about a javascript: URL in an href, which needs an allow-list of http: and https:, or about values placed inside <script>, inline event handlers or CSS. The OWASP Cross Site Scripting Prevention Cheat Sheet covers each context, and MDN's page on textContent explains how it differs from innerHTML.