What does the Hex to Text Converter do?
It reads hexadecimal bytes and gives you back the characters they stand for. Paste 48 65 6C 6C 6F and the answer is Hello — five bytes, five characters, updating as you type. There's no Convert button to press, because there's nothing worth pressing it for.
Underneath the answer sits the part most decoders leave out: a row per character, pairing each one with the exact bytes that produced it and its Unicode code point. For 48 65 6C 6C 6F that's 48 → H (U+0048), 65 → e (U+0065), and so on down. Read the Bytes column straight down and you have your input back.
That working matters more here than on a number converter, because hex to text is the one conversion where the bytes alone don't settle the answer. The two bytes C3 A9 are the single character é if they were written in UTF-8, and the two characters é if they were written in Latin-1. Both are real text. Neither is a bug. Nothing inside the bytes says which one the author meant — which is why this page asks you instead of guessing.
It handles up to 8,192 bytes, runs entirely in your browser, and never uploads what you paste. No account, no limit on how often you use it.
How hex becomes text
Hex is base 16. Each digit covers 0–9 and then A–F for the values 10 through 15, so two digits describe exactly one byte: 00 through FF, which is 0 through 255 in decimal. A byte is always two hex digits. That's the whole reason hex caught on for writing bytes down — the mapping is fixed-width and lossless, and you can split a dump anywhere without ambiguity.
Decoding runs in three steps. Split the digits into pairs. Turn each pair into a number. Look that number up as a character. Here's 4D 69 63 72 6F 61 70 70 taken apart byte by byte:
| Hex | Decimal | Character | Code point |
|---|---|---|---|
| 4D | 77 | M | U+004D |
| 69 | 105 | i | U+0069 |
| 63 | 99 | c | U+0063 |
| 72 | 114 | r | U+0072 |
| 6F | 111 | o | U+006F |
| 61 | 97 | a | U+0061 |
| 70 | 112 | p | U+0070 |
| 70 | 112 | p | U+0070 |
That lookup is dependable for any byte below 128, because those 128 values are the original ASCII characters and every encoding in common use agrees on them. It's why people say hex to ASCII and hex to text as though they were the same job. For bytes under 0x80 they are. Above 127 they part company, and the lookup stops being one table.
Separators don't matter on the way in. Spaces, colons, commas, hyphens and line breaks are stripped, and the 0x, \x, % and # prefix forms come off too. So 0x48 0x69, \x48\x69, 48:69 and 4869 all decode to the same Hi. Paste a hex dump exactly as you found it.
Choosing how to read the bytes
Once a byte goes above 7F, the encoding decides what you see. The Hex to Text Converter offers four readings, and the picker is the one real decision the page asks you to make.
| Encoding | Bytes per character | Where you meet it |
|---|---|---|
| UTF-8 | 1 to 4 | The web, JSON, modern files. Start here. |
| Latin-1 | Always 1 | Older Western-European data. Never fails, so it's the fallback. |
| UTF-16 LE | 2 or 4 | Windows APIs, .NET, most UTF-16 files in the wild. |
| UTF-16 BE | 2 or 4 | Java, network protocols, anything calling itself network byte order. |
Watch what one choice does to five bytes. Read 43 61 66 C3 A9 as UTF-8 and you get Café — four characters from five bytes, because C3 A9 is a single two-byte sequence for é. Read the identical bytes as Latin-1 and you get Café — five characters, because Latin-1 reads every byte on its own and turns C3 into à and A9 into ©. Same input, two defensible answers, one of them wrong for your data.
UTF-8 is the default because it's what almost everything written this century uses. Latin-1 is the fallback: it reads all 256 byte values and so it always returns something, though that something may not be what the author meant. UTF-16 has a tell worth memorising — for plain English text, every other byte is 00. The word Hi is 48 00 69 00 in UTF-16 LE and 00 48 00 69 in UTF-16 BE.
The bytes sometimes argue for a different reading, and the page says so rather than sitting on it. Paste FF FE 48 00 69 00 as UTF-8 and you get a mess plus a line telling you these bytes start with a UTF-16 LE byte-order mark — and a button that switches you to it. One tap, and the answer is Hi.
When you'll reach for a hex decoder
Most people land on a hex to text converter mid-investigation, not out of curiosity. A packet capture shows a payload as hex and you want to know whether it's JSON. Paste 7B 22 6F 6B 22 3A 74 72 75 65 7D and there's your answer: {"ok":true}, eleven bytes, plain ASCII throughout.
Database work throws off the same problem. A BLOB column, a hashed-looking field, a value some driver handed back as hex — dropping it in tells you in a second whether you're looking at text, binary, or something that was text before an encoding went wrong somewhere upstream.
Security and forensics work runs on it too. Hex is how malformed input gets written down in bug reports, how a file signature gets quoted, how a log line preserves bytes a terminal would otherwise eat. Decoding 1B 5B 33 31 6D gives you \e[31m — the ANSI escape that turns terminal text red. That's the kind of thing you want named, not swallowed.
And then there's coursework. Hex to ASCII is a standard exercise in a first systems class, and the working table is built for exactly that: it shows which bytes made which letter, so the answer comes with its own method attached rather than appearing from nowhere.
Here's what's notable about that list — every one of those jobs is a byte lookup that takes a millisecond. Yet the common shape for this on the web is a decoder buried three clicks inside a developer suite that wants an email address first, or a page that opens with a 14-day trial for a conversion a pocket calculator could do. A sign-up wall in front of a byte lookup isn't a product decision, it's a toll booth. The Hex to Text Converter is just the decoder.
When the output looks wrong
Most hex to text problems are one of five things, and all five have a tell.
| What you see | What it means | What to do |
|---|---|---|
| é or ’ where é or ’ should be | UTF-8 bytes read one at a time | Switch the encoding to UTF-8 |
| The character � | A sequence that isn't valid in the chosen encoding | Try Latin-1, or check for a truncated paste |
|  at the very start | A UTF-8 byte-order mark read as Latin-1 | Switch to UTF-8 — the mark is then removed for you |
| \n, \t or \x00 in the output | Real control characters, drawn as escapes | Nothing — Copy gives you the real characters |
| "This is one digit short" | An odd digit count; a byte is always two | Add the leading zero: A should be 0A |
Mojibake — the é case — is the one people find most alarming and it's the most harmless. The file is fine. The bytes are fine. Something along the way read UTF-8 as if it were one-byte-per-character. Nothing was lost, and switching the encoding gets your text back intact.
The replacement character is more interesting, because it marks real damage. The bytes DE AD BE EF read as UTF-8 give you three characters: DE AD decodes cleanly to ޭ (U+07AD), then BE and EF each come out as �. BE is a continuation byte with no lead in front of it; EF starts a three-byte sequence that never finishes. The page counts them and marks them in the working table instead of hiding them, because a dump that's 99% readable with three bad bytes in the middle is still worth reading — and knowing where the damage sits beats being told the whole thing failed.
Two inputs get refused outright rather than guessed at. 0b1010 is rejected with a pointer to the binary decoder, because those are all valid hex digits and decoding them as hex would hand you a confidently wrong pair of bytes. And a stray letter gets a specific reply: type O where you meant zero and the message asks you that directly, rather than saying "invalid input" and leaving you to hunt.
Related converters
Hex shows up in a lot of places, and the right next tool depends on what the digits mean. If your hex is a number rather than text — a memory offset, a colour value, a register — the hex to decimal converter reads the same digits as a quantity. The hex to binary converter expands each digit into its four bits, which is what you want when a specific flag bit is the question.
Going the other way, text to binary and text to unicode take characters and give you the numbers behind them. For the other common way of writing bytes as printable characters, the Base64 encoder and decoder does the same job with a different alphabet, and URL encoding is really hex in disguise — those %48 sequences are hex bytes with a percent sign in front.
All of them work the same way this one does: open the page, do the thing, close the tab. Ten percent of every dollar Microapp earns goes to charity, off the top, audited quarterly — the tools themselves just work.
Frequently asked questions
Why does my hex have an odd number of digits?
Almost always a missing leading zero. A byte is two hex digits without exception, so a value below 0x10 has to be written 09, not 9. Somewhere a program printed its bytes without padding and the zeroes vanished. The other common cause is a truncated copy — a selection that stopped one character early. The Hex to Text Converter tells you the exact digit count so you can work out which of the two you're dealing with.
Can I paste a hex dump with offsets and an ASCII column?
Not in one go. Separators are handled, but the offset column on the left of a classic dump is itself made of hex digits, so it gets decoded along with everything else and shifts your output. The ASCII column on the right is worse — letters like a through f are valid hex and get silently absorbed, while anything else throws an error. Select just the byte columns and paste those.
Does uppercase or lowercase hex matter?
No. 48656c6c6f and 48656C6C6F both decode to Hello. Hex digits are case-insensitive by definition; the working table normalises everything to uppercase because that's the convention in most dumps, but you can paste either.
Does it handle emoji and non-Latin scripts?
Yes, and the byte counts are the useful part. The bytes F0 9F 98 80 read as UTF-8 are one character — 😀, U+1F600 — built from four bytes. That's why a character count and a byte count are shown separately: for anything outside plain ASCII they disagree, and confusing the two is what makes text get truncated mid-character.
What does 0x mean in front of a hex byte?
It's a marker, not data. Programming languages use 0x to say "what follows is base 16" so that 0x10 isn't mistaken for ten. \x does the same inside string literals, and % does it in URLs. All of them are stripped here before decoding, so you can paste hex in whichever notation your source used.
Is hex encoding a form of encryption?
No, and the distinction is worth being firm about. Hex is a way of writing bytes down, not a way of hiding them — anyone can reverse it on this page in about two seconds, no key involved. It exists because bytes have no printable form of their own, so anything carrying arbitrary data through a text-only channel writes it in hex or Base64 instead. If something needs to stay private, that's encryption, and it's a different job. Treating hex as a secret is a genuinely common security mistake.
Is anything I paste stored or uploaded?
No. The decode is JavaScript running on your own machine, which is why it's instant and why there's no upload progress bar. Nothing is logged, nothing is kept, and closing the tab clears it. That's worth stating plainly, because what people paste into a hex decoder is often the contents of a packet capture, a database blob or a log line they're not supposed to email anywhere.