Encoding is two steps, and only the second one is arithmetic
People say "convert text to binary" as if it were one operation. It is two, and the interesting failures all live in the first. Step one turns characters into bytes, which requires a character encoding — the rule that says what byte or bytes stand for the letter A, or for é, or for a rocket emoji. Step two writes those bytes out in base 2, 8 or 16, which is pure notation and cannot fail.
This tool uses UTF-8 for step one, in both directions, without exception. That matters because the alternative you will meet online is UTF-16 code units, where every character becomes a 16-bit number and A comes out as 00000000 01000001 rather than 01000001. Neither is wrong; they answer different questions. UTF-8 is what a file on disk, an HTTP body and virtually every modern API actually contains, so it is the one that lets you compare output against something real.
Why some characters take more bytes than others
UTF-8 is variable width, and the width is determined by the code point, not by how the character looks.
| Code point range | Bytes | Leading byte pattern | Typical content |
|---|---|---|---|
| U+0000 - U+007F | 1 | 0xxxxxxx | ASCII: Latin letters, digits, basic punctuation |
| U+0080 - U+07FF | 2 | 110xxxxx | Accented Latin, Greek, Cyrillic, Hebrew, Arabic |
| U+0800 - U+FFFF | 3 | 1110xxxx | Most CJK, Devanagari, symbols, box drawing |
| U+10000 - U+10FFFF | 4 | 11110xxx | Emoji, historic scripts, rare CJK |
Every continuation byte after the leading one starts with 10. That is the property the whole design turns on: you can drop into the middle of a UTF-8 stream, look at one byte, and immediately tell whether it starts a character or continues one. It is also why a truncated multi-byte character is detectable rather than silently becoming garbage, and why the decoder here can tell you the bytes parsed but the sequence is invalid.
A worked example, because it makes the pattern concrete. The letter é is U+00E9, which falls in the two-byte range, so it encodes as 11000011 10101001 — hex C3 A9. Encode Café and you get five bytes from four characters. Decode those five bytes and you get Café back, unchanged. If instead you see Café, the file was UTF-8 but something read it as Windows-1252, which is the single most common encoding bug in existence and the reason that particular pair of characters is recognisable on sight.
What the parser is checking
Decoding is where pasted data goes wrong, so the errors are specific rather than a generic failure. A token can be rejected for containing a digit that does not exist in the chosen base — a 9 in an octal string, or an F in a binary one. It can be rejected for the wrong length, since binary needs exactly 8 digits per byte, octal 3 and hex 2. It can be rejected for a value above 255, which means it was not one byte to begin with. In every case you get the token number and the two before it, so you can find the spot in a long paste.
Unseparated input is split by fixed width, which is why the base selector matters more than it looks. A hex string with no letters in it — 34 35 36 — is indistinguishable from octal by inspection, and the automatic detection will guess. If the result is nonsense, set the base explicitly rather than assuming the input is corrupt. Nibble-split binary is handled: four-digit groups get paired back into bytes before parsing.
Where this stops being useful
Binary text is a teaching notation and a puzzle format, not a transport. If you are trying to move bytes through something that only takes text — a JSON field, a URL, an email body — base 2 is a terrible choice, at eight or nine characters per byte. Base64 costs about 1.33 characters per byte and every language has it built in. If you are looking at a hex dump to debug an encoding problem, a real hex viewer will show you offsets and the ASCII column alongside, which is what you actually need. And nothing here is encryption: converting text to binary hides it from nobody, since the transformation is public, reversible and has no key. It is a change of notation, and treating it as anything more is how people end up with a password in a config file that is technically obfuscated and practically plain text.
Questions people ask
Why is my binary different from another converter's output?
Almost certainly because the other one uses UTF-16 code units rather than UTF-8 bytes. In UTF-16, every character is at least 16 bits, so A becomes 00000000 01000001 instead of 01000001, and the output for plain English text is exactly twice as long. Some converters also emit UTF-32, giving 32 bits per character. Check the length of your output for a plain ASCII string: 8 bits per character means UTF-8, 16 means UTF-16, 32 means UTF-32.
It says the bytes parsed but the text is not valid UTF-8.
The numbers were all in range, but they do not form legal UTF-8 sequences. The two usual causes are a multi-byte character cut in half — a copy-paste that started or ended in the middle of one — and text that was never UTF-8 in the first place, most often Windows-1252 or Latin-1 from an older system, or Shift-JIS from a Japanese one. The lossy output is still shown with the bad bytes replaced, so you can usually see enough of the surrounding text to tell which case it is.
Does the output include a byte order mark?
No. A UTF-8 BOM is the three bytes EF BB BF at the start of a file, and it is optional and generally discouraged for UTF-8 since there is no byte order to mark. If you are decoding bytes taken from a Windows-generated file and the first character comes out as a strange invisible one, that is the BOM. It is a real part of the file, not a decoding error, and dropping the first three bytes removes it.
Is there a length limit?
No hard limit, but everything runs in your browser and the byte-layout table stops at 60 characters to keep the page responsive — the encoded output itself is always complete. Very large inputs will make the page sluggish before they fail, since the work is happening on your machine rather than a server. For anything past a few hundred kilobytes, a hex viewer or a two-line script is the better tool.
Can I use this to hide text?
It will stop a casual glance and nothing else. The transformation is public, deterministic and instantly reversible by anyone who recognises what they are looking at, and long runs of 0 and 1 are conspicuous rather than subtle. There is no key involved, so there is nothing to not know. If the goal is that someone cannot read it, that is encryption, which is a different tool and a different set of decisions about where the key lives.