Hex Decode

Paste a hexadecimal string below and click Decode to convert it back to text. All processing happens locally in your browser.

Spaces, colons, commas, hyphens and 0x prefixes are all stripped before decoding.
Copied!

What is Hex Decoding?

Hex decoding converts a hexadecimal string back to its original byte representation and then to text. The input can contain spaces, colons, or no separators between hex pairs.

Each pair of hex characters (00ff) represents one byte. The decoded bytes are interpreted as UTF-8 text.

Spaces, colons, commas, semicolons, full stops and hyphens are stripped before decoding, so hex copied straight out of a fingerprint or a dump usually works without tidying. The bytes are then read as UTF-8, and anything that is not valid UTF-8 is reported rather than mangled.

Debugging something that will not decode?

A payload that will not decode is usually a symptom rather than the fault: a double encoding somewhere in the pipeline, a charset assumed instead of declared, a token signed over bytes that are not quite the bytes anyone expected. We do this kind of work, on integrations, APIs and the systems that pass data between them.

Tell us what is breaking

Frequently Asked Questions

Why does my hex string fail to decode?
Usually an odd number of digits, or a character that is not a hex digit. Every byte needs exactly two digits, so an odd count means something was truncated or a digit was lost along the way. A stray character is often a lowercase L typed for a one, a capital O for a zero, or the tail of a copied line coming along for the ride.
Can I paste hex with spaces, colons or 0x prefixes?
Spaces, colons, commas, semicolons, full stops and hyphens are all stripped before decoding, so hex copied straight from a certificate fingerprint, a MAC address or a dump usually works without tidying. A 0x before every byte is not removed, so take those out first if your source has them.
What if the decoded bytes are not text?
That is the normal case rather than an error. Hex is a way of writing bytes down, and those bytes are frequently not text at all. This page decodes them as UTF-8 and says so plainly when they are not valid UTF-8, instead of printing replacement characters and letting you wonder. If you expected text and did not get it, check whether the bytes are compressed or encrypted.
How do I know which character encoding the bytes use?
From the hex alone, you do not. Nothing in a hex string records which encoding produced it; that information lives outside the bytes, in an HTTP header, a file format or a protocol specification. This page assumes UTF-8, which is right the overwhelming majority of the time, and that is why an invalid sequence is reported as binary rather than quietly turned into mangled characters. If you know the bytes are something else, decode them with a tool that lets you name the encoding.
Is hex decoding reversible?
Completely. Hex is a straight substitution, two characters for every byte, with nothing lost and nothing added, so encoding and decoding return exactly the bytes you started with. What is not always reversible is the step after it: turning bytes back into text needs the right encoding, and a byte sequence that is invalid in that encoding has no text form at all.