Decimal Character Reference Converter

Convert text to decimal HTML character references, or read numeric references and supported \uXXXX escapes embedded in text. This handles Unicode character references, not ASCII bytes or lists of numbers.

Runs locally in your browser

Convert text or embedded references

Paste directly into the input. Conversion runs in the browser without sending the input in network requests. There is no file input or batch mode.

  1. Enter text to encode, or text containing references to decode, and run the corresponding operation.
  2. Inspect the plain-text result and copy it. Editing the input or a conversion error clears the old result and disables copying.
  3. For another operation, paste the result into the input yourself, or clear both fields.

Decimal output and selective decoding

One numeric reference per supported code point

Encoding A你😀 produces A你😀. The emoji is one code point, not two surrogate references. Letters and spaces are encoded too: é becomes é, space   and LF 
. Output uses decimal numbers, not named references.

Three forms recognized inside the input

Decode accepts decimal A, hexadecimal A or A, and a lowercase \u followed by four hex digits, as in \u0041. Numeric references require a semicolon; hex digits accept either case. Surrounding plain text is kept.

😀, 😀 and the paired tokens \uD83D\uDE00 each produce 😀. This is token conversion, not whole JS/JSON string parsing or HTML execution.

Where strict HTML checks apply

he 1.2.0 applies strict HTML checks to encoding and numeric-reference decoding. It rejects references such as �, €, � and �. Encoding rejects NUL, C1 controls such as U+0080, U+FFFF and lone surrogates.

These HTML checks do not apply to the \uXXXX branch: \u0000 and \uFFFF decode to their code units. The final output check rejects only unpaired surrogates.

Old surrogate references �� are rejected, not joined into an emoji. Use 😀 instead.

Questions about numeric character references

Why does some malformed-looking text remain unchanged?

Only the three recognized forms are converted. \uZZZZ, \u{41}, \U0041, &#xZZ; and &#65 without a semicolon stay literal. So do &, plain numbers such as 65 66 and \n. This is not a validator for every malformed input or a UTF-8 byte decoder.

Will one decode operation expand nested references?

No. Both A and \u0026#65; become the literal text A, not A. Replacement text is not scanned again.

Are whitespace and empty input changed?

No trimming or Unicode normalization is added; empty input gives an empty result. The textarea normalizes actual CRLF/CR line endings to LF. The core can encode CR as 
, but strict numeric decoding rejects 
, so not every input can round-trip.

Recent tools: