Hex, Binary & ASCII Converter

How to use it

1. Paste anything. Text, hex, binary, decimal or octal — the format is detected for you.
2. Read every other format in the panes below. They all update as you type.
3. Adjust the output if you need commas instead of spaces, uppercase hex, or values without padding.

Nothing is uploaded. Every conversion runs in your browser.

One tool instead of five pages

Most converters give you one direction per page: text to hex here, hex to text there, binary to ASCII somewhere else. Going from text to binary means two hops through two pages.

This is one any-to-any matrix. Everything routes through the underlying bytes, so every representation is available at once:

input  →  bytes  →  text
                 →  hexadecimal
                 →  binary
                 →  decimal
                 →  octal

The bytes are the real content. The five formats are just different ways of writing the same numbers down.

The four number bases

Hex won because it maps onto bytes so neatly. One hex digit is exactly four bits, so two digits are exactly one byte, every time, with no arithmetic. Binary is unambiguous but eight times longer to write. Decimal needs one, two or three digits depending on the value, which makes columns of it hard to scan.

How text becomes bytes

Every character has a number. Encoding is the rule that turns those numbers into bytes.

Take Hi:

1. H is character number 72, i is 105.
2. Both fit in one byte, so that’s two bytes: 72 105.
3. In hex: 48 69. In binary: 01001000 01101001.

That’s the whole mechanism. Every conversion on this page is that, repeated.

What happens to accented characters and emoji

This is where “ASCII converters” quietly go wrong, so it’s worth being precise.

ASCII defines 128 characters, numbered 0 to 127, each one byte. That covers unaccented English and not much else. No é, no £, no 日, no emoji.

UTF-8 covers all of Unicode. It was designed so the first 128 characters are byte-for-byte identical to ASCII, which is why ASCII text is already valid UTF-8. Above 127, characters take two, three or four bytes.

So café is four characters but five bytes. The stats line under the output says both numbers, and points out when they differ. A tool that reports only one of them is hiding the thing most likely to trip you up.

The practical consequence: if you convert café to hex and someone decodes those bytes as Latin-1 instead of UTF-8, they get café. That mismatch — not the conversion — is behind the vast majority of mojibake you’ll ever see.

Reading the input tolerantly

Hex arrives in a dozen shapes and they should all work. These are all the same five bytes:

48 65 6c 6c 6f
48656c6c6f
0x48 0x65 0x6C 0x6C 0x6F
48,65,6c,6c,6f
48:65:6c:6c:6f

Spaces, commas, colons, semicolons, dashes, line breaks and 0x prefixes are all stripped before parsing. Case doesn’t matter.

Two things are still errors, because guessing would be worse than asking:

• An odd number of hex digits. 486 could be 04 86 or 48 60. There’s no way to know, and a leading zero is almost always what’s missing.
• A bit count that isn’t a multiple of eight. Something has been dropped. The error tells you how far off you are.

How the format is detected

Auto-detection runs from the most constrained alphabet to the least, because a narrower alphabet is stronger evidence.

1. Binary — only 0 and 1, and a whole number of bytes.
2. Hex — only 0-9 and A-F, even length, and either an 0x prefix or at least one letter A-F.
3. Decimal — a list of numbers, all 255 or below.
4. Text — anything else.

The ambiguous cases are real and worth knowing. 10101010 is valid binary, valid hex and a valid decimal number. It’s read as binary, because eight binary digits is exactly one byte and that’s the most specific reading. But 1010 is only four binary digits — not a whole byte — and 1010 as a decimal value is above 255, so it falls through to hex.

If detection guesses wrong, set the format explicitly. The dropdown always wins.

Worked example

Paste 48 65 6c 6c 6f 21 and leave the format on automatic.

Six bytes, six characters, all ASCII — so the byte count and character count match. Add an emoji and they stop matching, which is exactly the signal you want.

Converting by hand

Hex to decimal, for one byte: multiply the first digit by 16 and add the second. A-F are 10 to 15.

6C → 6 × 16 = 96, plus C which is 12 → 108. And 108 is lowercase l.

Binary to decimal: each position is worth double the one to its right — 128, 64, 32, 16, 8, 4, 2, 1. Add up the positions holding a 1.

01001000 → 64 + 8 = 72 → H.

Binary to hex is easier still, and it’s the reason hex exists: split into groups of four bits and convert each independently. 0100 1000 → 4 and 8 → 48. No arithmetic across the boundary, ever.

Where you’ll actually meet hex

Hex isn’t an academic exercise. It’s the default way of writing bytes across most of computing, and recognising it saves time.

The PNG one is worth trying. Paste 89 50 4E 47 0D 0A 1A 0A into the box and the text pane shows the readable part of a real PNG header. File signatures like this are how a program identifies a file type without trusting the extension.

Extended ASCII, and why it’s a mess

ASCII stops at 127, which leaves the top half of a byte — codes 128 to 255 — unclaimed. Through the 1980s and 90s, everyone claimed it differently.

Windows-1252 put curly quotes and the euro sign there. ISO-8859-1 put accented Latin letters there. KOI8-R put Cyrillic there. Code page 437 put box-drawing characters there. Same byte, completely different character, depending on a setting nobody wrote down.

So “extended ASCII” is not one thing, and a byte value like 233 has no single correct answer outside a stated encoding. This is the mess UTF-8 was built to end, and it’s why this tool treats everything as UTF-8 and says so rather than offering a dozen code pages that would each produce a different answer to the same question.

If you have bytes above 127 that decode to nonsense here, they’re probably in one of those legacy encodings. The give-away is text that’s readable but sprinkled with Ã, Â or â€ — that’s UTF-8 bytes being read as Windows-1252.

ASCII reference: printable characters

Codes 32 to 127. These are the characters you can actually see.

ASCII reference: control characters

Codes 0 to 31 are instructions rather than characters. Most are obsolete relics of teletype hardware, but a handful still matter every day.

The ones worth knowing: 9 (TAB), 10 (LF) which ends a line on Linux and macOS, and 13 (CR) which pairs with LF to end a line on Windows. That CR/LF difference is why a file moved between systems sometimes shows every line running together, or shows a stray character at each line end. If you’re diffing two files that look identical, this is usually why.

Related tools

Base64 is another way of writing bytes as text, and the Base64 encoder and decoder handles that specifically. If your input turned out to be a cipher rather than an encoding, the cipher decoder and identifier will work out which one and decode it. For bytes inside a web address, the URL encoder explains percent-encoding, which is hex with a % in front of each byte. The hash generator turns any of these bytes into a checksum, and the Discord timestamp generator covers the other common “what does this number mean” question.