Eight bits per character, in both directions, with the separator style you need for a code comment, a puzzle or a profile bio.
Computers do not store letters. They store numbers, and a character encoding is the agreed table that says which number means which letter. Converting text to binary is really two steps: look up the number, then write that number in base two.
The table underneath this tool is ASCII, standardised in 1963. It assigns 0 to 127 to the English letters, digits, punctuation and a set of control codes. Capital A is 65, lowercase a is 97, the digit 0 is 48 and a space is 32. Those are not arbitrary: the layout was designed so that useful operations fall out of the arithmetic.
The clearest example is letter case. A is 65 and a is 97, a difference of exactly 32, which is a single bit, the sixth. In binary A is 0100 0001 and a is 0110 0001. They differ in one position. That is why converting case was historically a single bitwise OR or AND rather than a lookup, and why the alphabet sits where it does in the table.
The digits are similarly deliberate. The character 7 is 55, and 55 minus 48 is 7, so converting a digit character to its value is one subtraction.
ASCII needs only seven bits, because 127 fits in seven. This tool pads every value to eight, and the padding is not decoration. It is what makes the output decodable.
Without a fixed width you cannot tell where one character ends and the next begins. The bits `1100001` could be one character or the tail of another. Fixed at eight, the stream splits cleanly every eight digits with no separator needed at all, which is why the joined output option still decodes correctly while looking like noise to a human.
Eight bits is one byte, and the eighth bit above ASCII's seven has a messy history. Through the 1980s it was used for competing regional extensions (Latin-1 for Western Europe, Windows-1252, KOI8-R for Russian, dozens of code pages) all disagreeing about what 128 to 255 meant. A document was only readable if you knew which page it was written in, which is the origin of a great deal of mojibake.
UTF-8 ended that by using the high bit as a continuation flag, encoding a character in one to four bytes while keeping the ASCII range byte-identical. That backwards compatibility is why UTF-8 won.
Because it writes exactly eight bits per character, it handles anything with a code point of 255 or below. Plain English is entirely inside that range and round-trips perfectly.
Beyond it, the conversion is lossy. An emoji, a mathematical bold letter or a CJK character has a code point far above 255 and does not fit in eight bits, so the value is truncated and the character will not come back. If you need those, the correct approach is to encode to UTF-8 bytes first (`new TextEncoder().encode(str)` in JavaScript) and convert those bytes, which is a different and longer output.
This is a deliberate limit rather than an oversight. The eight-bit form is what people mean by text to binary: it is what appears in puzzles, in code comments, in the classic `01001000 01101001` greeting. A UTF-8 byte stream is technically more correct and considerably less recognisable.
Decoding is forgiving in the other direction: it strips every character that is not a 0 or a 1, so binary pasted with spaces, line breaks, commas or stray text still resolves.
A few patterns make binary partly readable at a glance, which is useful when checking output rather than decoding it.
Every ASCII letter starts `010` or `011`. Uppercase is `010`, lowercase is `011`. So a run of bytes beginning `010` is shouting and one beginning `011` is not, before you decode a single character.
Digits all begin `0011`, and the last four bits are the digit itself in binary: `0011 0111` is 7. Space is `0010 0000`, the only common byte with that shape, so word boundaries are visible once you know it.
The last bit tells you parity of the code point, which sorts the alphabet into odds and evens, A, C, E are odd, B, D, F even. Rarely useful, occasionally handy for spotting a single flipped bit.
None of this makes binary a practical way to read text. It does make it possible to sanity-check a conversion, spot a truncated stream, or notice that what you were told is text is actually something else.
Almost never for storing text, that is what encodings are for, and no system stores your message as a string of ASCII ones and zeros.
The real uses are pedagogical and decorative. It is the standard way to teach place value in base two, and the conversion is concrete enough that students can verify it by hand. It appears in capture-the-flag puzzles and escape rooms as a first-layer encoding that looks cryptic and takes seconds to break. It shows up in profile bios and tattoos, where the appeal is precisely that it is unreadable at a glance.
It is also a reasonable obfuscation for something that should not be casually readable but does not need protecting, a punchline, a spoiler, an answer key. Binary is not encryption and offers no security whatever: anyone who recognises the format can decode it instantly, and search engines index it as text. Do not put anything sensitive in it.
Spaced groups of eight are the readable form and the right default. The byte boundaries are visible, you can count them, and a truncated stream is obvious because the final group is short.
Joined output with no separator is compact and still decodes, because the width is fixed. It is the form to use when the binary is decoration rather than something a reader will parse (a bio, a graphic, a tattoo) and the aesthetic matters more than legibility.
One byte per line suits a spreadsheet column, or a teaching context where each character sits beside its binary form. It is also the easiest to diff when you are comparing two conversions.
All three decode back identically, because the decoder ignores everything that is not a 0 or a 1 before splitting into groups of eight. You can convert in one form and paste in another.
Because the fixed width is what marks the character boundaries. Without it the stream could not be split back into characters. The padding is doing real work, not decoration.
No. Their code points are far above 255 and do not fit in eight bits, so they will not round-trip. Encoding to UTF-8 bytes first is the correct approach for anything outside plain ASCII.
Yes. The decoder strips everything that is not a 0 or a 1 before grouping into eights, so spaced, joined, line-separated or comma-separated input all work.
Because ASCII was laid out that way deliberately. A is 65 and a is 97, a difference of 32, the sixth bit, so changing case was historically a single bitwise operation rather than a table lookup.
No, and it should never be treated as one. It is an encoding: anyone who recognises the format decodes it in seconds, and search engines index it as ordinary text. Put nothing sensitive in it.
ASCII covers 0 to 127 in seven bits. UTF-8 extends that to every Unicode character using one to four bytes, while keeping the ASCII range byte-identical, which is exactly why it replaced the competing regional code pages.
Switch the direction control to decode and paste the binary. Grouping and stray characters do not matter; only the count of ones and zeros does, and it must be a multiple of eight.