Skip to main content
Calculator Answers

Hex to Text Converter

Source: WHATWG Encoding Standard · Source verified August 15, 2026

Blake Boege
Written by Blake Boege · Founder, Calculator Answers

Hexadecimal is a way of writing bytes, using two digits for each byte because one hex digit carries four bits. Turning those bytes into readable text takes a second step, a character encoding, which says which byte sequence stands for which character. This converter uses UTF-8, the encoding the web is standardised on, and decodes strictly: a byte sequence that UTF-8 does not allow is reported as an error rather than replaced with a substitute character. That is what separates decoding bytes from converting a number between bases, which is a different operation on the same digits.

Paste hexadecimal and get the text back. The digits are read two at a time as bytes, then decoded as UTF-8, which is what makes accented letters, non-Latin scripts and emoji come out right instead of coming out as fragments. Switch direction to turn text into hex.

See also: Binary Calculator, Data Storage Converter, and Character Counter.

Quick Answer

Read the digits two at a time as bytes, then decode those bytes as UTF-8. 48656c6c6f is five bytes and decodes to Hello; f09f9880 is four bytes and decodes to one character, the grinning face emoji.

Direction

Two digits per byte. Spaces, line breaks and commas are ignored, and a 0x prefix is ignored only where a byte can start. Anything else that is not a hex digit is reported rather than skipped.

Decoded text

5 bytes of UTF-8

Hello

1. U+0048 = 48H
2. U+0065 = 65e
3. U+006C = 6Cl
4. U+006C = 6Cl
5. U+006F = 6Fo

Each row is one character: its position, its Unicode code point, the bytes that spell it in UTF-8, and the character itself. Long results list the first 24 characters.

Was this helpful?

Examples

48656c6c6f

Hello

48 65 6C 6C 6F

Hello (spacing and case ignored)

0x48 0x69

Hi (0x prefixes ignored)

f09f9880

😀 (four bytes, one character)

How it works

Decoding happens in two steps, and it helps to keep them apart because only the second one can fail.

Step 1: digits to bytes

"48656c6c6f" → 0x48 0x65 0x6c 0x6c 0x6f

Two digits per byte. One hex digit carries four bits, so a pair carries eight, which is exactly one byte and a value from 0 to 255.

Step 2: bytes to characters

0x48 0x65 0x6c 0x6c 0x6f → "Hello"

Done with UTF-8. Bytes below 0x80 are the ASCII characters you expect; everything else is spelled out by a run of two, three or four bytes.

UTF-8 is not the only way bytes have ever been turned into text, but it is the one the web standardised on, and the WHATWG Encoding Standard tells new formats to use it exclusively. That is why it is the decoder here rather than an option buried in a menu.

What the input may contain

Real hex arrives in a dozen formats, so a few of them are cleaned up before the digits are read. Exactly these, and nothing else:

  • whitespace of any kind, anywhere, is ignored
  • commas are ignored, so comma-separated hex byte lists are accepted
  • a 0x or 0X prefix is ignored where a byte can start: at the beginning, or straight after whitespace or a comma
  • upper and lower case digits are treated the same

The prefix rule is deliberately narrow. 480x65 is reported as containing an x rather than quietly becoming 4865, because nobody can tell which of those two the writer meant.

The three ways it can fail

  • Not a hex digit. Something survived the clean-up that is not 0 to 9 or A to F. The message names the character so you can find it.
  • Odd digit count. The last byte is missing half of itself, and there is no safe way to fill it in.
  • Invalid UTF-8. The bytes are fine as bytes but do not spell legal UTF-8. The decoder runs in the Encoding Standard's fatal error mode, so it reports this instead of dropping a replacement character into your text and letting you believe it worked.

A byte-order mark is a fourth thing people get caught by, and it is not an error here. Bytes EF BB BF at the front decode to the character U+FEFF, which is invisible but real, and the byte count will tell you it is there.

Worked example: f0 9f 98 80

Four bytes, one character. UTF-8 marks a four-byte sequence by starting it with a byte in the range F0 to F4, and each of the three that follow carries six more bits:

  • F0 = 11110000, so three usable bits: 000
  • 9F = 10011111, so six more: 011111
  • 98 = 10011000, so six more: 011000
  • 80 = 10000000, so six more: 000000
  • 000 011111 011000 000000 = U+1F600

Which is the grinning face emoji. Split those same four bytes into pairs and read each as its own character and you get four unrelated symbols, which is exactly the failure this page exists to avoid.

Source

The decoding rules, the UTF-8 decoder and the fatal error mode this page uses are specified in the WHATWG Encoding Standard. Verified 15 August 2026.

Related calculators

Related Calculators

More tools from Education

Binary CalculatorConvert numbers between binary, octal, decimal, and hexadecimal. Perform binary addition, subtraction, multiplication, division, and bitwise operations.Data Storage ConverterConvert between decimal (KB, MB, GB, TB, PB) and binary (KiB, MiB, GiB, TiB, PiB) data storage units. Clear labels for 1,000-byte vs 1,024-byte conventions.Character CounterCount characters with and without spaces, plus words, lines, and paragraphs — perfect for limit-bound writing.

Frequently asked questions

It reads your digits two at a time. Each pair is one byte, and 48 65 6c 6c 6f is five bytes. Bytes on their own are just numbers, so the second step is to decode them with a character encoding, and this page uses UTF-8. That is the step people usually mean by 'hex to text', and it is the step that can fail.

Because UTF-8 has rules about which byte sequences are legal, and yours breaks one of them. A byte like C3 announces a two-byte character and must be followed by a byte between 80 and BF; C3 28 is not, so C3 28 is rejected. Overlong forms, lone surrogates and truncated sequences are rejected for the same reason. If your data really is text, it is probably in a different encoding than UTF-8.

A byte is always two hexadecimal digits, so an odd count means the last byte is incomplete and there is no honest way to finish it. Adding a leading zero or dropping the last digit would both change your data, so the page says what is wrong instead of guessing.

Yes, that is the reason it decodes UTF-8 rather than reading each byte as a character. f0 9f 98 80 is four bytes and one character, U+1F600. A converter that turned every byte pair into a character would give you four pieces of nonsense instead.

The binary calculator treats your input as one number and rewrites it in another base, so hexadecimal 48656C6C6F becomes the decimal 310939249775. This page treats the same digits as a sequence of separate bytes and decodes them as characters, which gives Hello. Same digits, different question.

No. The decoding runs in your browser using the encoding support already built into it, so nothing you type is sent anywhere to be converted.