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.

Developer Implementation Guide: Safe Encoding in JavaScript

Cross-Site Scripting (XSS) is one of the most common web vulnerabilities. It occurs when untrusted user input is rendered directly into the DOM without being properly encoded. While modern frameworks like React and Vue automatically encode text bindings, you must manually encode data if you are using Vanilla JS or innerHTML.

Creating a Safe Encode Function

The safest and most robust way to encode HTML entities in Vanilla JavaScript is to leverage the browser's own DOM API, rather than attempting to write complex regex replacements.

function encodeHTML(str) {
  // Create a detached text node
  const textNode = document.createTextNode(str);
  
  // Create a detached div
  const div = document.createElement('div');
  
  // Append the text node to the div
  div.appendChild(textNode);
  
  // The browser automatically encodes the text content
  return div.innerHTML;
}

// Example usage:
const maliciousInput = "<script>alert('XSS!')</script>";
console.log(encodeHTML(maliciousInput));
// Output: &lt;script&gt;alert('XSS!')&lt;/script&gt;
        

This technique is virtually bulletproof because it uses the exact same parsing engine the browser uses to render the page, ensuring no obscure edge cases or malformed tags slip through your regex filters.