UTF-8 Hex to Text Converter

Paste a string of hex bytes into this UTF-8 hex to text converter and it hands back the readable text those bytes encode, whether that is plain English, accented letters or an emoji. It is a free online tool that works in your browser, so you can paste your hex data from a log, a database dump or a debugging session and see the decoded text with no registration. Because UTF-8 stores every Unicode character in one to four bytes, a trustworthy decoder has to read each multi-byte sequence correctly, and the sections below show you exactly how that works so you can verify any result by hand.

What Is a UTF-8 Hex to Text Converter?

A hex to text converter takes numbers written in base 16 and turns them into the characters they stand for. When the characters follow the UTF-8 standard, you need a UTF-8 aware decoder rather than a simple lookup, because one character can span several bytes. This page's hex to utf8 converter does that work for any text you throw at it: English, Greek, Hindi, Chinese, symbols and emoji. Use the hex to octal converter when a legacy Unix tool expects octal but your data is stored in hexadecimal.

Understanding Hexadecimal and Base-16 Values

Hexadecimal uses sixteen digits, 0-9 and A-F, where A is 10 and F is 15. Each hex digit holds exactly four binary bits, so two digits describe one byte, which is why programmers prefer base-16 notation over long strings of ones and zeros. The byte E2 is simply 226 in decimal and 11100010 in binary. Hex values like these are the everyday shorthand for raw data in memory dumps, network captures and file editors, and the same notation is what you see whenever an encoding problem forces you to look at bytes.

UTF-8 Encoding, Unicode and Code Points

Unicode assigns every character a number called a code point, and UTF-8 encoding is the rulebook that turns a code point into one to four bytes. It is a variable-width character encoding, so common letters stay short while rarer symbols take more room. The first 128 code points match ASCII exactly, which makes UTF-8 backward-compatible with ASCII and explains why plain English hex often decodes the same under either scheme.

How UTF-8 Encoding and Decoding Work Byte by Byte

Every UTF-8 byte announces its role in its leading bits, so a decoder never has to guess where one character ends and the next begins. That self-describing design is the reason the format took over the web and is the thing worth learning if you ever debug raw bytes.

Leading Bits and Continuation Bytes

A single byte beginning with 0 is an ASCII character. A byte beginning with 110 starts a sequence of two bytes, 1110 starts a sequence of three bytes, and 11110 starts a sequence of four bytes, so a character takes anywhere from 1-4 bytes. Every continuation byte that follows carries the binary prefix 10, which is how a decoder recognises that it is still inside the same character.

Rebuilding a Code Point From a Byte Sequence

To decode a three-byte character, strip the prefix bits and join what is left. With the lead byte written as \(b_1\) and the two continuation bytes as \(b_2\) and \(b_3\), the code point is:

Two-byte characters use \((b_1 \mathbin{\&} \texttt{0x1F}) \times 2^{6} + (b_2 \mathbin{\&} \texttt{0x3F})\), and four-byte characters add a fourth term with \(2^{18}\) for the lead byte. The result is the code point, which the decoder then maps to a glyph.

UTF-8 Decoding Worked Example: Santiago ✓ 🚀

Take the 17 hex bytes 53 61 6E 74 69 61 67 6F 20 E2 9C 93 20 F0 9F 9A 80. The first nine bytes (53 through 20) are all below 80, so each is one ASCII character and together they spell "Santiago ". The next byte, E2, is 11100010, so it opens a three-byte character:

\((\texttt{E2} \mathbin{\&} \texttt{0F}) \times 4096 = 8192\), \((\texttt{9C} \mathbin{\&} \texttt{3F}) \times 64 = 1792\) and \(\texttt{93} \mathbin{\&} \texttt{3F} = 19\), which add up to 10003, or U+2713, the check mark ✓. After another space (20), F0 is 11110000, a four-byte lead, and the bytes F0 9F 9A 80 resolve to U+1F680, the rocket 🚀. The final text is Santiago ✓ 🚀: 12 characters stored in 17 bytes.

Tracing a Truncated Gift Note Through UTF-8 Decoding

A support engineer is chasing a ticket: a customer typed "Zażółć 🎁" into the gift note field of an order, but the confirmation email shows only "Zażółć". Suspecting a charset problem, the engineer runs SELECT HEX(gift_note) on the orders table and pastes the result into the converter:

5A 61 C5 BC C3 B3 C5 82 C4 87 20

That is 11 bytes, and decoding them as UTF-8 returns Zażółć with a trailing space, 7 characters. Reading the bytes explains why the accents survived: C5 BC is ż (U+017C), C3 B3 is ó (U+00F3), C5 82 is ł (U+0142) and C4 87 is ć (U+0107). Each is a two-byte sequence, comfortably inside what the column can store.

Next comes the hex captured in the application log for the same request, which is 15 bytes long: the same 11 bytes followed by F0 9F 8E 81. The lead byte F0 is 11110000, so those four bytes form a single character, U+1F381, the gift emoji. The database stopped right before it.

MySQL's legacy utf8 charset holds at most three bytes per character, and the check against that limit is where a four-byte emoji gets cut. That is the named cause, so the next action is specific: run ALTER TABLE orders CONVERT TO CHARACTER SET utf8mb4 on a staging copy, resubmit the same note, and confirm that HEX(gift_note) now returns all 15 bytes. Once it does, decoding that dump shows the full "Zażółć 🎁" and the ticket can close.

Where a Hex to Text Converter Earns Its Place

Developers, analysts and administrators reach for a hex to text converter more often than you might expect. These are the situations where it saves real time.

Web Development and API Responses

In web development, hex-escaped strings show up in API responses, JSON and XML payloads and HTML entities. Decoding the bytes shows whether a mangled character was already broken when it left the server or was damaged by the browser, and UTF-8 decoding at each hop tells you which hop introduced the damage. It also supports internationalization work, since you can confirm that text in many languages survives the trip.

Database and Storage Debugging

Garbled text in databases is a classic encoding bug. When MySQL rejects an emoji, converting the stored value to hex reveals whether it is a four-byte sequence that a three-byte charset cannot hold. The fix is the utf8mb4 character set. Checking the hex of a column before and after a migration is the quickest way to prove nothing changed in storage.

Forensics, Logs and System Administration

Forensics analysts and system administration teams decode hex dumps, network packets and log files to read the text hiding in binary captures. This is also routine data analysis when a vendor hands over a raw export with no readable fields. Because every byte is shown, nothing is silently reinterpreted along the way, and the encoding of each field stays visible. A mislabeled encoding in a log header is one of the most common surprises, and the hex view settles it. Strict UTF-8 decoding of the raw bytes then proves what the text really says.

UTF-8 Decoding in Python, JavaScript and PHP

For programming use, the same job takes a line or two of code. In Python, bytes.fromhex(...) followed by .decode() turns hex into a string, and the decode() call lets you choose how errors are handled. In JavaScript, the TextDecoder API decodes a Uint8Array in the browser, while Node.js uses the Buffer class, where Buffer.from(hex, 'hex') builds the bytes and a Buffer toString call decodes them. In PHP, hex2bin followed by mb_convert_encoding does it. These routines are handy to know, but a browser-based tool is faster for a one-off check.