Hex to Text Converter

Q: Why does my hex produce garbled characters instead of words?

Because those bytes are not text. Hex represents raw bytes, and only some byte sequences correspond to readable characters — the rest are image data, compressed archives, executables or encrypted material. The tool inspects the result and tells you when it is not valid text, and recognises common file signatures so it can say what you actually pasted. If it reports a PNG or a ZIP, the bytes are genuinely a file and there is no text to recover.

Q: What does the odd number of digits error mean?

One byte is always exactly two hex digits, so a valid hex string has an even length. An odd count means a digit is missing somewhere — usually a leading zero that got dropped when the value was copied or printed. If your string starts with a single digit, try adding a 0 in front of it. If it ends oddly, check that the copy was not truncated.

Q: Can I paste hex with spaces, colons or 0x prefixes?

Yes, all of them. Hex arrives formatted in a dozen different ways depending on where it came from: colons in MAC addresses, dashes in GUIDs, spaces in memory dumps, 0x prefixes in source code, newlines in multi-line output. The tool strips all of those before decoding, so you can paste directly from a debugger, a packet capture or a log without cleaning it up first.

Q: Which text encoding does it use?

UTF-8, which is what the overwhelming majority of modern systems use. That matters because the same bytes mean different things under different encodings — the byte sequence c3 a9 is é in UTF-8 but shows up as two separate accented characters if read as Latin-1. If your decoded text has strange pairs of accented characters where single ones should be, you are probably looking at UTF-8 bytes that something else already misread.

Q: Is this the same as Base64?

Both represent binary data as printable characters, but they trade off differently. Hex uses 16 characters and takes two per byte, so it doubles the size but stays trivially readable — you can spot a byte value at a glance. Base64 uses 64 characters and takes about 1.33 per byte, so it is far more compact but effectively unreadable to a human. Hex is what you want for debugging and inspection; Base64 is what you want for transmitting data efficiently.

Q: What is a byte-order mark and why does it appear?

A byte-order mark is an invisible three-byte prefix — ef bb bf in UTF-8 — that some editors, particularly on Windows, write at the start of a file to declare its encoding. It is invisible when the text is displayed but very much present in the bytes, which is why a file can look identical to another and still produce a different hash or fail a comparison. The tool flags it when it sees one, because it explains a whole category of otherwise baffling bugs.

Convert hexadecimal to readable text and text back to hex, with a byte-level view that tells you when the data is not text at all.

Hexadecimal (0 chars)

Decoded text (0 chars)

Conversion happens entirely in your browser. Nothing you paste is uploaded or stored anywhere.

What It Does

Hexadecimal is how raw bytes get written down when a person needs to read them. Every byte becomes exactly two characters from 0 to f, so a stream of bytes turns into a string you can print in a log, paste into a bug report or compare by eye. This tool converts in both directions: hex in and readable text out, or text in and hex out. What it adds beyond the conversion is an honest account of what those bytes actually are. Not every byte sequence is text, and a converter that hands back a screenful of replacement characters without explanation is not helping. This one checks whether the result is valid UTF-8, counts how much of it is printable, and recognises the signatures of common file formats — so when your hex is really a PNG or a gzip archive, it says so.

When to Use It

A log file or packet capture recorded a payload as hex and you need to read what was actually sent.
You are debugging an encoding problem and want to see the exact bytes behind text that looks correct but compares as different.
An API returns a hex-encoded field and you need to confirm whether it contains text, binary data or something already encoded again.
You want to check whether a file starts with the magic number you expect before trusting its extension.
You need to produce a hex literal for a test fixture or a protocol definition from a known string.

Worked Examples

48656c6c6f2c20576f726c6421

Plain ASCII text with no separators. Each pair maps to one character — 48 is H, 65 is e — which is why hex is readable in a way Base64 never is.

de:ad:be:ef

Colon-separated, the format MAC addresses and packet dumps use. These four bytes are not valid text, so the tool reports them as binary rather than pretending otherwise.

89 50 4e 47 0d 0a 1a 0a

The first eight bytes of every PNG file, space-separated as a memory dump would show them. The tool recognises the signature and tells you this is an image rather than trying to render it as text.

Features

Hex to text and text to hex in one place

Accepts spaces

colons

dashes

newlines and 0x prefixes

File signature detection for PNG

JPEG

GIF

PDF

ZIP

gzip and ELF

Valid UTF-8 checking with a clear verdict

Printable and control character counts

Byte-order mark detection

Byte count shown alongside character count

Optional uppercase and separated hex output

One-click copy in either direction

Entirely browser-based with no uploads

How to Use

1. Choose the direction you want — hex to text, or text to hex. 2. Paste your input into the box; formatting characters like colons and spaces are handled automatically. 3. The converted result appears immediately, with a note about what the bytes actually are. 4. For text to hex, use the formatting options to add separators or switch to uppercase. 5. Click Copy to take the result, or Clear to start again.

Common Mistakes

Assuming every hex string decodes to words. Most bytes in the world are not text, and a garbled result usually means the data is genuinely binary rather than that the conversion failed.
Dropping a leading zero. Printing a byte without padding turns 0f into f, which makes the whole string odd-length and shifts every byte after it if you paste it somewhere expecting pairs.
Mixing up characters and bytes. In UTF-8 an accented letter is two bytes and an emoji is four, so a ten-character string is very often not twenty hex digits.
Reading UTF-8 bytes as Latin-1. This is what produces the classic Ã© where an é belongs — the bytes are correct and the interpretation is wrong.
Forgetting an invisible byte-order mark. Three extra bytes at the start of a file are enough to break a checksum comparison or a string equality test while looking identical on screen.

Frequently Asked Questions

Why does my hex produce garbled characters instead of words?

What does the odd number of digits error mean?

Can I paste hex with spaces, colons or 0x prefixes?

Which text encoding does it use?

Is this the same as Base64?

What is a byte-order mark and why does it appear?