Text to Binary
Convert text to binary, octal, decimal or hex — and back again.
How Text-to-Binary Conversion Works
Computers store text as numbers. This tool encodes your text as UTF-8 bytes, then writes each byte in the base you choose — binary (8 digits), octal (3), decimal (1–3) or hexadecimal (2). ASCII characters map to a single byte, while emoji and accented characters span several: é is two bytes and 😀 is four, so the byte count runs ahead of the character count. Everything runs locally in your browser — your text is never uploaded.
Use the swap button to decode in the other direction. The decoder accepts any separator — spaces, commas, newlines, dashes — and tolerates 0b, 0o and 0x markers, so output from any of the options above reads straight back in. An unrecognised group is named in an error rather than skipped, because a decoder that quietly ignores what it cannot read returns a plausible answer built from part of your input.
Binary, octal and hex bytes have a fixed width, so those can be written with no separator at all and still split apart correctly — which is why padding is on by default. Decimal cannot: a decimal byte is one to three digits, so 72105 could be any of several byte sequences and the tool asks for a separator instead of guessing.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Producing a byte-level view of a string to explain why a length check disagrees with what someone can see on screen.
- Building a fixture for a bit-manipulation exercise or a low-level parsing test.
- Checking which bits differ between two nearly identical strings when a checksum refuses to match.
- Preparing binary output for a puzzle, a teaching example or a CTF challenge.
- Confirming that a character you expect to occupy one byte really does occupy one byte.
How it works in practice
A worked example
A protocol document specifies a field as bytes and you need to see what a short piece of text with an accent in it actually occupies.
café
01100011 01100001 01100110 11000011 10101001 4 characters · 5 bytes
Four characters, five groups of eight. The first three are plain ASCII and cost one byte each, and the accented letter costs two — the pair beginning 11000011 is the UTF-8 encoding for a code point above 127, where the leading bits announce how many bytes follow. That is why a length limit expressed in bytes and one expressed in characters are different limits, and why the count underneath reports both rather than one number that could be read either way.
The edge case that catches people
So the answer depends on a choice nobody usually mentions. The same four characters in a Latin-1 world would be four bytes, with the accented letter as a single value, and both encodings are internally consistent — which is exactly how mojibake happens: bytes written as UTF-8 and read as something else produce plausible-looking nonsense rather than an error. Japanese or emoji cost three and four bytes respectively, so a field of sixteen bytes holds sixteen letters, five Japanese characters, or four emoji.
When not to use this tool
Binary is a representation, not an operation, so this is a viewer rather than a converter in any useful sense. It tells you what bytes a string is made of and can never tell you whether those bytes are correct — for that you need the specification at the far end and a comparison against it. And if the goal is to move data through a channel that only carries text, this is the wrong encoding entirely: eight characters per byte is a 700 percent overhead where Base64 costs about 33.
Frequently Asked Questions
- Which encoding is used for the bytes?
- UTF-8, so ASCII characters produce one 8-bit group each while accented and non-Latin characters produce two to four. Assuming one byte per character is the classic bug — 'é' is two bytes (C3 A9), not one.
- Why are results grouped in eights?
- Because a byte is 8 bits, and byte boundaries are what any decoder needs to find. Grouping is purely for human legibility — the underlying stream has no separators, so the spaces must be stripped before decoding.
- Should leading zeros be kept?
- Yes, always. 'A' is 01000001, and writing it as 1000001 loses the byte width, making the stream undecodable because the reader can no longer tell where one character ends.
- Is binary text encryption?
- No. It is a change of notation, entirely reversible with no key — like writing a number in hex. Anyone can decode it, so it provides no confidentiality whatsoever.
- How much larger is the output?
- Eight times, plus separators — so roughly 9x with spaces. This is why binary is used for illustration and puzzles rather than storage or transmission, where the raw bytes are obviously preferable.
Common errors and gotchas
- Dropping leading zeros, so an eight-bit group becomes seven and everything after it is read off by one position.
- Assuming one character is one byte. Anything outside ASCII takes several, and the output length reflects that immediately.
- Reading the groups as characters rather than bytes, which breaks the moment a multi-byte character appears.
- Treating the result as obfuscation. It is a direct, fully reversible view of the same data with no secret involved.
- Pasting output that a terminal has wrapped, which inserts real line breaks in the middle of a byte.