Cookies for analytics and advertising
We use cookies for analytics and advertising, both sent to Google. Refusing changes nothing you can see.Read the privacy page
Hex decode
Paste hexadecimal in whatever shape you copied it and read the text behind it. Separators are ignored, so a dump from a debugger, a packet capture or a piece of documentation all work without being tidied up first. Bytes that do not form valid text are reported as exactly that rather than replaced with question marks.
Where it runs
Nothing is uploaded, because there is no file — it is worked out in this page.
No queue, no account
It answers as fast as your machine can, and it never asks who you are.
As often as you like
Nothing is counted and nothing is capped — answering again costs us nothing.
How it works
- Paste the hexadecimal into the box, separators and all.
- Read the text. Two digits become one byte, and the bytes are read as UTF-8.
- If it reports that the bytes are not text, the input was probably not a string — see below.
It accepts the shape you copied, not a tidied one
Whitespace, colons, commas and a `0x` in front of every byte are all stripped before anything is read. That covers a debugger watch window, a packet capture, a certificate fingerprint, a C array literal and the output of `xxd`, which are the five places a run of hexadecimal actually comes from.
The alternative is a tool that demands a clean unbroken string, which means retyping or a find-and-replace before you can ask your question. Every one of those steps is a chance to drop a digit, and dropping one digit shifts every byte after it — producing text that is confidently wrong rather than obviously broken.
An odd number of digits is refused rather than guessed
Each byte is exactly two digits, so an odd count means something is missing and there is no way to know which end. Padding the front and padding the back give different answers, and both look plausible.
So it stops and says so. That is worth more than an answer here: an odd digit count almost always means the copy was truncated or a character was lost, and knowing that immediately is faster than reading a decoded string and wondering why it starts mid-word.
When the honest answer is that it is not text
Plenty of hexadecimal is not a string. A compiled instruction, a compressed block, a key, an image header — all of them decode to bytes that form no valid UTF-8, and most decoders hand back a screen of replacement characters anyway.
This one reports the byte count instead. That distinguishes two situations that look identical otherwise: your input was wrong, or your input was fine and the content simply is not text. The second is not a failure, and treating it as one sends people looking for a mistake they did not make.
Reading the first few bytes tells you what you have
Most binary formats announce themselves. `89 50 4e 47` is a PNG, `ff d8 ff` a JPEG, `25 50 44 46` a PDF — that one spells `%PDF` in ASCII, which is why the first four bytes of a PDF are readable here while the rest is not. `50 4b 03 04` is a ZIP, and therefore also a modern Office document or a JAR.
`ef bb bf` is not a format at all: it is a UTF-8 byte-order mark, and finding it at the start of a run explains a whole class of bug where the first field of a file refuses to match a string it visibly equals.
Hex decode: common questions
Do I need to remove the spaces or the 0x prefixes first?
No. Whitespace, colons, commas and 0x prefixes are all stripped before anything is read, so a dump from a debugger, a packet capture or a piece of documentation works as copied. That is deliberate: tidying it by hand is where a digit gets dropped, and one dropped digit shifts every byte after it.
It says there is an odd number of digits. What does that mean?
That the input cannot be split into bytes, because each byte is exactly two digits. Something was truncated or a character was lost in the copy. It refuses rather than guessing, because padding the front and padding the back give different answers and both look plausible.
Why does it say the bytes are not text?
Because they are not. A lot of hexadecimal is a key, an instruction, a compressed block or an image header, none of which forms valid UTF-8. Rather than hand you a screen of replacement characters, it says how many bytes there were — which tells you the input was fine and the content simply is not a string.
Which encoding does it assume?
UTF-8, which subsumes ASCII, so plain English text decodes identically either way. If the bytes are UTF-16 the result will look like text with a null between every character, and that is the signal that you are holding a different encoding rather than a broken decoder.
Is my input sent anywhere?
No. It is decoded in this page and never leaves your device. Hexadecimal pasted into a tool like this is routinely a key, a token or a fragment of a packet capture, so this is one of the tools where running locally is the point rather than a nicety.