HTML Entity Encoder & Decoder Online

What are HTML entities and why do they matter?

An HTML entity is a special sequence of characters that represents a reserved or non-printable character in HTML markup. They start with an ampersand (&) and end with a semicolon (;). The entity < renders as <, & renders as &, © renders as ©. Defined originally in HTML 4.01 and extended in HTML5 to over 2,000 named entities, they exist for two reasons: escaping reserved characters (so the browser doesn't think your text is markup) and typing characters that aren't on your keyboard (em dashes, math symbols, currency).

The five mandatory escapes — the ones that XSS-prevention guides drill into every web developer:

If your application takes user input and renders it inside HTML without escaping these five characters, you have an XSS vulnerability. Every modern web framework escapes by default; raw string concatenation or "trust-us" templating bypasses that protection. This is why innerHTML with user data is dangerous and textContent is safe.

Named vs numeric vs hex — three ways to encode the same character

For the five mandatory escapes, named entities are universally supported and most readable. For uncommon symbols (em dash, em space, math operators, arrows), numeric entities are safer because every parser recognizes them. Always include the trailing semicolon — most browsers tolerate missing semicolons in HTML5, but XML and strict parsers reject the entity entirely.

HTML5's named-entity gotchas

• ' only became official in HTML5. It works in modern browsers but breaks in XHTML 1.0 — use ' if XHTML compatibility matters.
• Some "obvious" names don't exist. There's no &asterisk; or $ — those are plain ASCII. Don't over-escape.
• Case matters. Ä = Ä, ä = ä — different characters.

Useful named entities by category

Currency & math

Punctuation & whitespace

Arrows

HTML entity encoding for XSS prevention — the critical rules

XSS (Cross-Site Scripting) happens when user-supplied content is rendered as HTML/JavaScript instead of as text. The fix: encode user input before placing it in an HTML context. But "an HTML context" is plural — different contexts need different encoding.

The classic mistake: HTML-escaping content that ends up inside JavaScript. < becomes a literal in JS — the < is never recovered. Use the right escape for the destination context, not the source.

HTML escaping in 8 programming languages

JavaScript

// Modern: use textContent (no encoding bugs possible)
el.textContent = userInput;          // Safe ✓

// If you MUST build HTML strings, escape manually
function escapeHtml(s) {
  return s.replace(/[&<>"']/g, c => ({
    '&': '&amp;', '<': '&lt;', '>': '&gt;',
    '"': '&quot;', "'": '&#39;'
  }[c]));
}

// To DECODE entities (use a textarea — the browser does it)
function decodeHtml(s) {
  const ta = document.createElement('textarea');
  ta.innerHTML = s;
  return ta.value;
}

Python

import html

html.escape("<script>alert(1)</script>")
# '&lt;script&gt;alert(1)&lt;/script&gt;'

html.escape("It's & \"quoted\"", quote=True)
# 'It&#x27;s &amp; &quot;quoted&quot;'

# Decode
html.unescape("&lt;p&gt;Hello&lt;/p&gt;")  # '<p>Hello</p>'

PHP

// Mandatory: htmlspecialchars (escapes 5 reserved chars)
echo htmlspecialchars($input, ENT_QUOTES | ENT_HTML5, 'UTF-8');

// htmlentities — encodes ALL applicable entities (rarely what you want)
echo htmlentities($input, ENT_QUOTES | ENT_HTML5, 'UTF-8');

// Decode
echo html_entity_decode($input, ENT_QUOTES | ENT_HTML5, 'UTF-8');

Java

// Apache Commons Text
import org.apache.commons.text.StringEscapeUtils;

String safe = StringEscapeUtils.escapeHtml4(userInput);
String back = StringEscapeUtils.unescapeHtml4(safe);

// OWASP Java Encoder (recommended for XSS prevention)
import org.owasp.encoder.Encode;
String safe = Encode.forHtml(userInput);
String safeAttr = Encode.forHtmlAttribute(userInput);
String safeJs = Encode.forJavaScript(userInput);  // different escape!

Go

import "html"

escaped := html.EscapeString("<script>")
// "&lt;script&gt;"

unescaped := html.UnescapeString("&lt;p&gt;hi&lt;/p&gt;")
// "<p>hi</p>"

// In Go templates, html/template auto-escapes by default — use it:
import "html/template"
t := template.Must(template.New("x").Parse(`<p>{{.}}</p>`))
t.Execute(os.Stdout, "<script>")  // automatically escaped

Ruby

require 'cgi'

CGI.escapeHTML("<script>alert(1)</script>")
# "&lt;script&gt;alert(1)&lt;/script&gt;"

CGI.unescapeHTML("&lt;p&gt;hi&lt;/p&gt;")
# "<p>hi</p>"

# In Rails ERB, the <%= %> syntax auto-escapes
<%= user.name %>        # auto-escaped, safe
<%= raw user.name %>    # NOT escaped — only when you've already trusted the input

Rust

use html_escape::{encode_text, decode_html_entities};

let safe = encode_text("<script>");
// "&lt;script&gt;"

let back = decode_html_entities("&lt;p&gt;");
// "<p>"

// Or use Askama / Tera templates — they auto-escape

Bash (recode / sed / xmlstarlet)

# GNU recode
echo '<p>Hello & world</p>' | recode html..ascii
# "&lt;p&gt;Hello &amp; world&lt;/p&gt;"

# Plain sed (5 mandatory chars)
sed -e 's/&/\&amp;/g' -e 's/</\&lt;/g' -e 's/>/\&gt;/g' \
    -e 's/"/\&quot;/g' -e "s/'/\&#39;/g"

# Decode with xmlstarlet
echo '&lt;p&gt;hi&lt;/p&gt;' | xmlstarlet unesc

HTML entity best practices

• Always use auto-escaping templating engines. Jinja2, ERB, Thymeleaf, html/template (Go), React's JSX — all escape by default. Manual escaping is bug-prone.
• Use textContent in JavaScript, not innerHTML, when inserting user data. Eliminates the encoding question entirely.
• Never trust input from anywhere. Database content, third-party APIs, your own admin panel — all can be sources of XSS payloads.
• Encode at the boundary, not the storage. Store raw user input; encode only when rendering. Lets you change templates and re-render correctly.
• Pick the right encoder for the context. HTML escape, JS escape, URL encode, CSS escape — they're all different. OWASP's library handles them all.
• Layer defenses with CSP. Even if XSS slips through, a tight Content Security Policy blocks inline-script execution.
• Sanitize, don't escape, when allowing some HTML. If users paste rich content, use DOMPurify (JS) or Bleach (Python) to strip dangerous tags. Don't try to write a regex sanitizer.
• Don't HTML-escape data going into JSON. JSON has different rules — use JSON.stringify or your language's JSON library.