Q: What is the difference between named and numeric entities?

Named entities use a memorable label: `©` for ©, `€` for €. Numeric entities use the character's Unicode code point: `©` (decimal) or `©` (hex) both also produce ©. Named entities are shorter and human-readable but cover only ~2,000 specific characters. Numeric entities work for every Unicode character including emoji. Modern HTML accepts both freely.

Q: Why are decimal and hex entities both valid?

The HTML spec accepts both — `©` and `©` produce the same © character. Decimal is more common in hand-written HTML and configuration files. Hex is more common when working from a Unicode code-point chart, since Unicode is documented in hex (e.g. U+00A9). Pick whichever your team's style guide prefers. Our tool defaults to decimal but you can switch with one click.

Question 1

What are HTML entities and when do I need them?

Accepted Answer

HTML entities are special sequences (`&`, `<`, `'`) that represent characters which would otherwise be interpreted by the browser as markup. The five characters `& < > " '` MUST be encoded whenever user-supplied content is inserted into HTML to prevent the browser from treating it as HTML structure or attributes — the foundation of XSS prevention. You may also use entities for non-ASCII characters in legacy HTML where the source file is ASCII-only.

Question 2

What is the difference between named and numeric entities?

Accepted Answer

Named entities use a memorable label: `&copy;` for ©, `&euro;` for €. Numeric entities use the character's Unicode code point: `&#169;` (decimal) or `&#xA9;` (hex) both also produce ©. Named entities are shorter and human-readable but cover only ~2,000 specific characters. Numeric entities work for every Unicode character including emoji. Modern HTML accepts both freely.

Question 3

When should I encode only the "dangerous five" vs everything?

Accepted Answer

Dangerous-five mode (`& < > " '`) is the correct choice for any modern HTML output where the source file is UTF-8 (the universal default since 2010). Encoding more is unnecessary bloat that hurts file size and readability. Encode-all mode is only needed for legacy systems that require an ASCII-only HTML source (e.g. some old email clients, some embedded systems with restricted character sets).

Question 4

Is my text sent to any server?

Accepted Answer

No. Encoding, decoding, and entity-table lookup all run in your browser via JavaScript. User submissions, pre-sanitization payloads, internal CMS content, or even leaked credentials you're cleaning up — none of it ever leaves your device.

Question 5

Does this tool prevent XSS attacks?

Accepted Answer

Encoding the dangerous five is the foundation of safe HTML output, but it is not the complete picture. (1) For JavaScript contexts (inside `<script>` or event handlers), HTML encoding alone is not enough — you also need to escape backslashes, control characters, and stay aware of context-switching attacks. (2) For URL attributes, HTML-encode the URL AND validate the protocol (block `javascript:`). (3) For rich text, use a vetted server-side sanitizer (DOMPurify, sanitize-html). Our tool handles the HTML-body encoding correctly but is not a substitute for context-aware encoding everywhere.

Question 6

Does this tool handle emoji and astral-plane Unicode correctly?

Accepted Answer

Yes. We iterate by code point (using `for…of` over the string), which means emoji like `🚀` (U+1F680) are treated as a single character and encode to a single `&#128640;` entity — not as two broken UTF-16 surrogate halves. Most online entity converters get this wrong on emoji and split them into two invalid entities. Test with the "Mixed Unicode" sample to see.

Question 7

What does the decoder do with unknown named entities?

Accepted Answer

It leaves them as-is and reports them in the stats footer. So `&unknownthing;` passes through unchanged. This is deliberately lenient — silent data loss on an unrecognised entity is far worse than showing the user exactly what arrived. If you need a permissive decoder that maps every HTML5 entity, run the source through `document.createElement` + `innerHTML` in your own code; for safety, stick with this tool's explicit unknown-handling.

Question 8

Why are decimal and hex entities both valid?

Accepted Answer

The HTML spec accepts both — `&#169;` and `&#xA9;` produce the same © character. Decimal is more common in hand-written HTML and configuration files. Hex is more common when working from a Unicode code-point chart, since Unicode is documented in hex (e.g. U+00A9). Pick whichever your team's style guide prefers. Our tool defaults to decimal but you can switch with one click.

Question 9

How is this different from JavaScript's built-in escape functions?

Accepted Answer

JavaScript has no built-in HTML-encode function — only URL-encode (`encodeURIComponent`) and the legacy `escape` (which is broken and shouldn't be used). Most projects ship a small `escapeHtml(str)` helper or import one from a framework. Our tool is the no-dependency version of that helper, exposed as a UI plus the ability to decode in reverse. Pair with our URL Encoder/Decoder for full percent-encoding coverage.

Character	Named Entity	Decimal	Hex	Why It's Required
&	&	&	&	Starts every other entity — must be encoded first
<	<	<	<	Starts a tag — un-encoded enables tag injection
>	>	>	>	Closes a tag — pairs with < for full injection
"	"	"	"	Breaks out of double-quoted attribute values
'	'	'	'	Breaks out of single-quoted attribute values

Free HTML Entity Encoder & Decoder Online

Bidirectional in One Click

XSS-Safe Encoding

Full Unicode

100% Client-Side

The XSS-Safe HTML Entity Encoder for Modern Web Apps

The Dangerous Five: HTML's Required Encodings

Context-Aware Encoding (Where HTML Entities Fit)

A Safe-Output Workflow for User-Submitted Content

Related Encoding & Web Utilities