The five characters & < > " ' are the ones that change parsing in HTML text content and double-quoted attribute values. Replacing them with named entities (&, <, >, ") and one numeric entity (' for the single quote, since ' is not in HTML4) is enough for rendering server-generated text inside element bodies. Note that we escape & first by listing it first in the regex character class, but order inside [&<>"'] does not actually matter because each match is one character; the danger is hand-rolling sequential replace calls, where doing & last would double-encode the others. Use this function for plain text inserted between tags.

Attribute context has more attack surface than text content because some browsers accept unquoted, single-quoted, double-quoted, and even backtick-delimited attributes. Adding the backtick (`) and equals (=) to the escape map defends against payloads that try to break out of an unquoted attribute by injecting evil onerror=alert(1). This still assumes you wrap the attribute in real quotes; if you concatenate values into unquoted attributes you have already lost. Pair this helper with double quotes around the attribute and you have a safe baseline for any string-into-attribute templating.

escapeHtml only solves the case where you want the user's input to appear as literal text. The moment you want a user to provide markup that survives rendering (rich-text editors, markdown previews, embedded HTML email), entity escaping is exactly the wrong answer because it makes everything literal. For that case you need an allowlist-based sanitiser like DOMPurify, which parses the HTML, drops dangerous elements (<script>, <iframe>), strips dangerous attributes (onerror, javascript: URLs), and serialises back. The decision tree above is the cheat sheet: text content uses this snippet, rich content uses DOMPurify, and URL attributes always need a separate URL-scheme allowlist. Do not write your own HTML sanitiser; the parser quirks alone are a multi-year project.