The five characters, and why the ampersand comes first
< opens a tag, > closes one, & opens an entity, and " and ' terminate attribute values. Replace them with <, >, &, " and ' and a string can be dropped into a document without any of it being read as structure. The order of the replacements is not arbitrary: the ampersand has to be substituted first, because doing it later would also rewrite the ampersands introduced by the other four and produce &lt; everywhere. Every correct implementation does the ampersand first, and that includes this one. Conversion happens in your browser and nothing is uploaded.
Escaping is context-dependent, and this is not a sanitiser
Which characters are dangerous depends entirely on where the string lands. In a text node, < and & are enough. In a quoted attribute value you also need the quote character in use, and in an unquoted attribute value — which is legal HTML and a genuinely bad idea — a space or a slash is enough to break out, so entity escaping does not save you. Inside a <script> block the HTML parser looks for </script before the JavaScript parser sees anything, so HTML entities are not decoded there at all and escaping them accomplishes nothing. In a style block, a URL, or an event handler attribute, the rules are different again, and a value that goes into href can be a javascript: URL that no amount of character escaping makes safe.
So: this tool converts characters. It does not inspect markup, it does not strip tags, and it has no opinion about what is safe. If you are accepting HTML from users and intending to render it, you need a real sanitiser with an allowlist of elements and attributes — DOMPurify in the browser, or the equivalent for your server language — and you need it applied at the point of output, in the right mode for the context. Use this for the case it fits: showing a code sample, reading an entity-encoded string, checking what a template is doing to a value.
Named entities, numeric references, and '
HTML5 defines more than two thousand named entities; this tool knows about eighty of the ones that turn up in real documents and leaves the rest alone rather than guessing. Numeric references are the reliable alternative and always resolve: — in decimal and — in hex both address a Unicode code point directly, so any character at all can be written that way. One historical wrinkle: ' is an XML entity that HTML4 never defined. Every current browser handles it, but older mail clients and some XML-to-HTML pipelines will render it literally, so ' is the safer output. Unescaping accepts both. If your document is served as UTF-8, which it almost certainly is, there is no reason to entity-encode non-ASCII characters at all — the option is here for the occasional system that mangles anything above ASCII in transit.
JavaScript string escaping is a different problem
HTML escaping stops the markup parser from seeing structure. JavaScript escaping stops the string literal from terminating early. It handles the backslash itself, the quote character you are using, and the control characters — newline, carriage return, tab. It also handles U+2028 and U+2029, the line and paragraph separators, which are invisible, survive a copy and paste from a word processor, and were treated as line terminators by JavaScript parsers before ES2019, breaking any literal that contained one. Where the two problems meet is a string embedded in an inline <script>: JS escaping alone leaves </script> intact inside your string, and the HTML parser will end the block there regardless of what the JavaScript means. The fix is to escape the < as \u003c as well, which this tool does not do — for that case, use JSON.stringify and then replace the angle brackets, or better, put the data in a <script type="application/json"> block and parse it, so no escaping question arises at all.
Questions people ask
What happens if I escape something twice?
The ampersands from the first pass get escaped again, so < becomes &lt; and the reader sees the literal text "<" on the page instead of a less-than sign. This is the single most common templating bug, and it comes from a framework that auto-escapes on output being handed a value that was already escaped on input. The fix is to escape in exactly one place, at output, and store raw values.
Some entities did not convert back.
They are not in the eighty-odd this tool knows. Rather than guess, unrecognised named entities are passed through unchanged so you can see exactly what was left. If you need one of them, its numeric form always works, and a full HTML5 entity table will give you the code point.
Is escaping enough to prevent XSS?
Only for the specific context it matches, and only if you also control the surrounding markup. Escaping the five characters is correct for a text node and for a quoted attribute value. It does nothing inside a script block, nothing for an unquoted attribute, and nothing for a javascript: URL in an href. If your input is markup that has to render as markup, character escaping is the wrong tool entirely and you need a sanitiser with an allowlist.
Can I use the JS escape output in JSON?
The double-quote result is compatible with JSON in practice, since JSON accepts \\n, \\t, \\uXXXX and escaped double quotes. The differences to know about: JSON has no single-quoted strings and no \\x escape, so the single-quote option produces something JavaScript accepts and JSON does not. If you are generating JSON programmatically, JSON.stringify is the correct tool and will handle the edge cases this does not.