What is the difference between decimal and hex entities?

Both reference the same Unicode code point. A decimal entity writes the number in base 10, like for a non-breaking space, while a hex entity writes it in base 16, like . Browsers treat the two forms identically.

Does this handle characters above U+FFFF?

Yes. Emoji and other astral-plane characters have a single code point above 65535, and the tool emits one numeric entity for the whole code point rather than splitting it into surrogate halves, which keeps the output correct and compact.

Can I encode only special characters?

By default every character is converted so the output is fully ASCII-safe, which is useful for email and legacy systems. The named-entity tool is a better fit when you only want to escape markup-critical characters and keep text readable.

Will it decode named entities too?

Decoding expands numeric decimal and hex references plus the five core named entities amp, lt, gt, quot, and apos, so mixed input round-trips cleanly. For the full named-entity table, use the dedicated named-entity decoder.

Why use numeric entities at all?

They guarantee a character displays correctly even when the page encoding is uncertain or limited to ASCII. They are common in XML, email templates, and exported data where a reliable, encoding-independent representation is needed.

What is the HTML Numeric Entity Encoder/Decoder?

Encode any text as numeric HTML entities in decimal ( ) or hexadecimal ( ) form using Unicode code points, and decode numeric and named entities back to characters. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

HTML Numeric Entity Encoder/Decoder

Name: HTML Numeric Entity Encoder/Decoder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Numeric HTML entities reference characters by their Unicode code point rather than by name, so any character at all can be written in pure ASCII. This tool encodes text to decimal or hexadecimal numeric references and decodes them back.

How it works

Encoding reads each Unicode code point of the input and emits it as a numeric reference in the base you choose:

decimal:  char -> &#<codePoint>;     "A" -> &#65;    " " -> &#160;
hex:      char -> &#x<HEXcodePoint>; "A" -> &#x41;   " " -> &#xA0;

Because it works on full code points (via the string iterator), characters above U+FFFF such as emoji become one entity, not a broken surrogate pair. Decoding parses &#NN; and &#xNN;, converts the number to a code point, and rebuilds the original character with String.fromCodePoint.

Decimal vs hex — when each form is preferred

Both forms are semantically identical: é and é are the same é to every browser. The practical difference is readability and context:

Decimal is more readable for developers who think in decimal code points and is the form used in most documentation examples.
Hex aligns naturally with CSS \00E9 escape syntax and Unicode charts, which list code points in hexadecimal, making it easier to cross-reference.
Some older XML processors and HTML-to-text email converters handle one form better than the other, so if a system rejects one, try the other.

Worked example

For example, encoding the word café to decimal numeric entities produces:

c → &#99;
a → &#97;
f → &#102;
é → &#233;

The full encoded string is café. Every character, including the plain ASCII letters, is replaced, making the result completely ASCII-safe.

The non-breaking space U+00A0 becomes   in decimal and   in hex. Non-breaking spaces are invisible to the eye but cause layout differences, and encoding them as numeric entities makes them visible and portable in email templates.

An emoji such as 🎉 sits at code point U+1F389 (above U+FFFF) and encodes as the single entity 🎉 in decimal — not as a pair of surrogate half-values, which would be wrong.

When to use numeric encoding vs named entities

Numeric encoding encodes every character, turning the output into a fully ASCII string with no multibyte sequences. This is the right choice for:

Email templates and legacy mailers — some clients mis-render raw UTF-8 but handle numeric references reliably.
XML documents — XML only recognises a handful of named entities by default; numeric references work universally.
Exported data that must pass through systems of unknown encoding.

If you only need to escape the characters that break HTML markup (<, >, &, ") while keeping the rest readable, the named-entity tool is a lighter touch.

Common mistakes to avoid

Forgetting the trailing semicolon renders the entity wrong in some parsers — &#233 (no semicolon) may not be recognised. The tool always adds the semicolon.
Decoding nested encoded text twice is a common mistake: if text has already been HTML-decoded once, running it through a decoder a second time will misparse any literal & in the decoded output.
Encoding already-encoded entities turns & into &amp;, double-encoding the ampersand. If your input has already gone through HTML encoding, decode it first.