Free HTML Entity Encoder & Decoder

What HTML entities do

HTML uses <, >, &, and " as structural characters — they define tags, attributes, and entity references themselves. To display these characters as literal text on a page, or to safely embed user-submitted content without breaking layout or letting attackers inject scripts, you replace them with entities: <, >, &, ". This encoding is the first line of defense against cross-site scripting (XSS) — any user-generated text you render into HTML must be HTML-entity-encoded to prevent attackers from injecting <script> tags. This free HTML entity encoder handles all three notation styles (named, decimal-numeric, and hexadecimal) and processes any character including full Unicode.

How to use the HTML entity encoder

1. Pick your mode — Encode (text → entities) or Decode (entities → text).
2. Paste your input. For encoding, paste raw text or HTML you want to display as literal characters. For decoding, paste text with entity references.
3. Choose an entity style:
   • Named — <, most readable, works in most modern browsers and email clients
   • Numeric — <, universally supported everywhere HTML is parsed
   • Hex — <, compact for large code points, standard for XML
4. Toggle “Encode ALL non-ASCII” if your destination system requires pure ASCII output (rare but sometimes needed for legacy email systems).
5. Click Convert →. Copy or download from the result panel.

The three entity styles compared

When to use which style

Named entities — most readable

Best for hand-written HTML where a human will read the source. & instantly reads as “ampersand,” while & requires memorizing character codes. Named entities are supported by every modern browser but a few (like ') are HTML5-only and can fail in older email clients or feed readers.

Numeric entities — universal safety

Use when compatibility across every possible renderer matters — legacy email clients, feed readers, XML parsers, older browsers. Every HTML/XML parser ever built understands &#DDDD;.

Hex entities — the XML standard

Same compatibility as numeric decimal, more compact for high Unicode code points, and required by some strict XML processors. Popular for representing emoji and CJK characters where decimal numbers get long (a smile emoji is 😀 or 😀).

HTML entities and XSS protection

Cross-site scripting (XSS) is the most common web application vulnerability class. It happens when user-controlled input is rendered into HTML without proper escaping, allowing attackers to inject <script> tags or JavaScript event handlers. HTML entity encoding is the first defense: convert < to < and no script can be injected via that path.

But encoding alone isn’t total protection. A complete defense also requires:

• Content Security Policy (CSP) headers to limit script sources
• Input validation — reject impossible values at the boundary
• Context-aware encoding — HTML content, HTML attributes, JavaScript strings, and CSS values each need slightly different escaping
• HttpOnly cookies so session cookies can’t be stolen by XSS if it does occur

For most content, entity encoding via this tool (or your framework’s equivalent) is the single biggest safety win.

Common use cases

Displaying code snippets on a blog — Show <div> as literal text without the browser parsing it as a tag. Encode with named entities for readability.

Escaping user comments — Any user-submitted text you render into HTML must be entity-encoded. This tool is fine for one-off encoding; production apps should use their framework’s built-in escaping.

Newsletter emails with special characters — Some email clients don’t render certain Unicode correctly. Encoding to numeric entities maximizes compatibility.

XML feeds (RSS, Atom, sitemap.xml) — XML is stricter than HTML. Any text containing <, >, &, or " must be entity-encoded or wrapped in <![CDATA[…]]>.

Debugging — Paste HTML source from a “view source” into Decode mode to read what a page really contains after entities are resolved.

HTML entity encoder comparison

Pro tips

• Encode & first, then everything else. If you encode < first to <, then encode & after, you’ll double-encode into <. Always start with ampersand.
• Modern HTML doesn’t need most Unicode encoded. A UTF-8 HTML document can contain 你好, 日本語, and 🎉 as raw characters. Only encode Unicode if your destination system requires pure ASCII.
• Named entities for readable HTML, numeric entities for maximum compatibility, hex for XML.
• Don’t rely on entity encoding for sensitive data. It’s for display safety, not encryption. Anything encoded to entities is trivially decoded.
• Encoding inside attribute values matters too. An unescaped quote inside an attribute (title="hello "world"") breaks the HTML. Use " for double quotes inside double-quoted attributes.