Binary Text Converter
Turn binary byte groups into text and text into binary — with decimal, octal and hex views — entirely on this device.
Radix and separator shape the byte groups.
Converting whole numbers between bases? That's the Number Base Converter.
Press ? for shortcuts
Do it offline:$ xxd -b file.txt
How to use it
- Paste either kind of input. A run of 0s and 1s eight digits or longer raises the Detected: Binary bytes badge, and until you pick a direction yourself the tool follows what it detects; choosing a tab, clicking the badge or pressing the s key pins your choice until the input is cleared.
- Pick the byte radix — Binary, Octal, Decimal or Hex — to spell the same bytes four ways. The separator select shapes encoded output: a space between groups, one group per line, or no separator at all for the fixed-width radices.
- Watch the chips under the panes. Decoding accepts spaces, newlines and commas wherever they fall, splits separator-less streams at the group width, and pads short groups — every one of those moves is announced, none is silent.
- Copy the output, download it as a file, or share a link that carries the tool state. Input that looks credential-shaped is kept out of the between-visits buffer, and the share action warns before it puts such input in a URL.
Paste groups like 01001000 01101001 and read them back as text, or type text and get its UTF-8 bytes as 8-bit binary groups — with decimal, octal and hex spellings of the same bytes one select away. A character can be several bytes, and every byte becomes exactly one group. Decoding reads your separators for you, each repair is declared as a chip, and the conversion never leaves this device.
How it works
The pipeline has three fixed steps. Text is a sequence of code points; one TextEncoder pass turns those code points into UTF-8 bytes; each byte — a value 0 through 255 — is then spelled as one group in the radix you chose: eight digits in binary, three in octal, two in hex, one to three in decimal. Decoding walks the same road backwards, and because the byte count comes from that single encoder pass, the status line, the announcement and the downloaded file always agree on it.
UTF-8 is why the group count can outrun the character count. An ASCII letter spends one byte, so H is just 01001000. é is code point U+00E9, which UTF-8 stores in two bytes — 11000011 10101001 — so one visible character becomes two groups. A CJK character like 水 takes three bytes, and 😀 takes four: it is one code point, U+1F600, kept as a surrogate pair in a JavaScript string but written as exactly four bytes here.
Decoded bytes are shown as text only when they truly are text: the whole buffer must survive a strict UTF-8 decode, the rules RFC 3629 lays down. A group like 11111111 is byte 0xFF, which no valid UTF-8 sequence lets stand alone, so the result is classified as binary and previewed as hex rather than rendered as garbage characters. The page never guesses around the spec.
Examples
Hi01001000 01101001The default view: two characters, two UTF-8 bytes, two 8-bit groups. H is byte 0x48, and 01001000 is that byte's eight bits — a spelling of the byte, not a number converted between bases.
110 151HiThe same two bytes arriving as octal. One byte is always one group, so the decimal spelling is 72 105 and the hex spelling is 48 69 — pick the radix that matches your source and the text comes out identical.
0100100001101001HiA separator-less stream still decodes: sixteen digits split cleanly at the byte width, and the chip records it — "1 unseparated digit run was split into 2 8-digit groups". A longer run that does not divide by eight refuses instead, because padding the middle of a stream would invent bits.
😀11110000 10011111 10011000 10000000One emoji, four groups: 😀 is the single code point U+1F600, and UTF-8 spends four bytes on it. The note chip counts the gap — "1 character uses more than one UTF-8 byte, so there are more groups than characters".
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
é is two groups, 水 is three
Characters beyond ASCII spend more than one byte: é encodes as 11000011 10101001 and 水 as 11100110 10110000 10110100. A note chip appears whenever at least one character does this, so a group count larger than the character count is explained on the spot instead of looking like a bug.
Not every byte pattern is text
Decoding 11111111 produces byte 0xFF, which cannot appear alone in UTF-8, so the output pane keeps its fixed shape and shows a classification note with a first-bytes hex preview — never a row of replacement characters pretending to be a result. Copy and download still carry the exact bytes.
Short groups are padded, and say so
A seven-digit group like 0100100 reads as 00100100 — byte 0x24, a $ — with a position-anchored chip for each occurrence. Up to twenty such chips are listed; past that, one honest line counts how many more were padded without being listed.
Commas and tabs separate too
Decode accepts spaces, newlines, tabs, CRLF line ends and commas between groups, and declares the non-canonical ones with a single chip. Encode output is stricter on purpose — it uses exactly the separator you chose and nothing else.
Decimal needs its separator
Decimal groups run one to three digits, so a run like 72105 has more than one valid split; the page refuses it and asks for separators rather than picking a reading. Encoding to decimal with the separator set to none is refused for the same reason — a typed refusal, never a silent fallback.
Leading zeros stay decimal
072 decodes as byte 72 — a leading zero never flips a token into octal here, and no chip fires. Octal is its own entry on the radix select, three digits per byte from 000 to 377; 400 and up refuses, because a byte tops out at 255.
A BOM is text like any other
U+FEFF at the start of input encodes as 11101111 10111011 10111111 — three real bytes. The page neither strips it nor warns about it: if the mark is in your text, it is in your bytes, and hiding that would misreport the payload.
Broken surrogates become U+FFFD
An unpaired half of a surrogate pair has no UTF-8 form, so it encodes as the replacement character with the warning "input contains an unpaired surrogate; it was encoded as U+FFFD" — the output stays well-formed and the substitution is on the record.
Common errors
'2' at position 14 is not a binary digit (use 0 or 1)- Digits are checked against the radix before anything else, and the first wrong one is named with a one-based position — Jump to error puts the cursor on it. A 2 in a binary paste usually means the groups are decimal; switching the radix select is the fix, not editing the paste.
Binary group at position 1 is 9 digits — binary needs 8 digits per byte- Fixed-width radices split only on exact multiples: nine binary digits are one byte plus a leftover bit, and padding a remainder in the middle would fabricate data the paste never had. Recover the missing digit or remove the stray one.
Decimal group '256' at position 1 is 256 — a byte cannot exceed 255- A byte holds 0 through 255, so 256 can never be one. The octal variant of this message adds the ceiling in its own spelling, 377. A value past the ceiling is usually a sign the input is not per-byte groups at all.
Decimal group at position 1 is 5 digits — separate decimal bytes with spaces or newlines (1-3 digits each)- Unlike the fixed-width radices, decimal gives no way to cut 72105 into bytes without guessing between readings. Put a space, newline or comma between the bytes and the same digits decode cleanly.
Decimal groups have no fixed width, so without a separator the byte boundaries are ambiguous — choose the space or newline separator.- The encode-side twin of the rule above: decimal output with no separator could never be decoded back unambiguously, by this page or anything else. Binary, octal and hex may drop their separators because every group is the same width.
Input is larger than the 1 MB limit for this tool. For bigger payloads use the CLI: xxd -b file.txt- Past the limit the page refuses the whole input instead of converting part of it — a truncated conversion would look finished. The banner's xxd line prints the same 8-bit groups for a file of any size, on your own machine.
FAQ
What's the difference between binary to text and binary to decimal?
This page treats binary as bytes of text: every 8-bit group is one byte, and the bytes are read as UTF-8, so 01001000 01101001 is the two-letter string Hi. Reading 11111111 as the integer 255 — number-base arithmetic, fractions, signed widths — is the Number Base Converter at /base-converter. The two questions look alike and share nothing.
Why do the groups have eight bits?
Because the unit is the byte — eight bits, values 0 through 255, the width files and network protocols agree on; RFC 20 put ASCII in an eight-bit frame for network interchange back in 1969. Shorter pastes still decode — a seven-digit group is left-padded with a chip saying so — but encoded output is always full bytes.
Is this ASCII or UTF-8?
UTF-8, which contains ASCII byte-for-byte: for letters, digits and common punctuation an ASCII table and this page agree exactly. The difference starts beyond ASCII — é here is two bytes, and any single-group spelling of it belongs to a different encoding such as Latin-1. The multi-byte chip tells you the moment the distinction matters.
Do I need separators between the bytes?
Not for binary, octal or hex on decode: a stream whose length divides evenly by the group width splits itself, with a chip recording the split, and spaces, newlines, tabs and commas all count where present. Decimal is the exception in both directions, because its groups vary from one to three digits and an unseparated run is ambiguous.
Can it convert a file to binary?
No — this page converts pasted text up to 1 MB, and file workflows live elsewhere: /hex-to-text reads a dropped file as an offset dump, and /base64-decode handles payloads that arrive as Base64. On your own machine, xxd -b file.txt prints exactly these 8-bit groups for any file, at any size.
Is anything I paste uploaded?
No. The conversion runs in this tab — small inputs inline, larger ones in a background worker on the same device — and no server receives, logs or stores what you type. The only persistence is an optional on-device buffer for your last input, and anything credential-shaped is kept out of even that.
Keyboard shortcuts
- ⌘/Ctrl + Enter
- Re-run the conversion now, ahead of any debounce.
- ⌘/Ctrl + S
- Download the output as a file instead of saving the page.
- ⌘/Ctrl + C
- Copy the groups or the decoded text when no selection exists.
- ⌘/Ctrl + Shift + C
- Copy that same output regardless of any selection.
- s
- Swap encode and decode (inactive while typing in a field).
- t
- Cycle the color theme (same typing rule).
- ? or ⌘/Ctrl + /
- Open the shortcut reference for this page.
- Esc
- Close the topmost overlay and nothing more.