Security & devFree
Free text to binary converter. Encode text to 8-bit binary or decode binary back to text in your browser.
Last updated 14 October 2026
Text becomes bits here by way of UTF-8, which uses one byte for the ASCII range and two, three or four for everything else. So the number of bits you get out depends on which characters went in, not on how many. Measured:
A: one byte, eight bits, 01000001.é: two bytes, sixteen bits, 11000011 10101001.The status line always tells you the byte count, which is the honest unit, and the output is grouped in eights so you can count the bytes yourself. If you were expecting one group per character, that expectation only holds for plain unaccented English.
You can see the structure of UTF-8 in those bits. A one-byte character starts with a 0. The first byte of a two-byte character starts 110, a three-byte one starts 1110, a four-byte one starts 11110, and every continuation byte starts 10. That is why é is 11000011 10101001: a two-byte lead followed by one continuation. It is also what makes the encoding self-synchronising, so a decoder can find the start of the next character after a corrupt byte.
Most converters decode bytes to text with a non-strict decoder, which silently replaces anything invalid with the replacement character �. You then cannot tell a genuine � in the original from a decoding failure. This tool uses a strict decoder and changes what it shows you instead. Measured:
01000001 01000010 decodes to AB, reported as “2 bytes of valid UTF-8 text”.11111111 is not valid UTF-8 at all. It shows FF and says “1 byte · not valid UTF-8 text, so the bytes are shown as hex”.So if you get hex back, the bits are real and the text is not: either they are not UTF-8, or they are a fragment cut mid-character, or they are not text at all. A single byte with the high bit set is the commonest case, and it usually means the data was in a single-byte encoding such as Latin-1 rather than UTF-8.
Measured: the bytes 61 0D 62, which are a, a carriage return, b, come back as hex with the note “holds a carriage return, which a text box cannot show”.
That is a genuine constraint of the web platform rather than a shortcut here. The HTML standard says a textarea’s API value is “the element’s raw value, with newlines normalized”, and that it is “normalized so that line breaks use U+000A LINE FEED (LF) characters”. So if the decoded text were put in a box, the carriage return would be converted to a line feed on its way in, and you would be shown something that was not what you decoded. Hex is the only honest answer.
The same constraint is why the encode direction has a line-ending choice at all. You cannot type a carriage return into the box, so it has to be asked for. Measured, on two lines of text:
01100001 00001010 01100010.00001101 inserted before each 00001010.Pick CRLF when the bytes are destined for something that expects Windows line endings, such as an HTTP header block, an email or a file read by an old Windows tool.
Switching the input to hex lets you go from bytes to bits without retyping them. Separators are stripped, so spaces, commas, colons, semicolons, underscores, hyphens and 0x prefixes are all accepted. Measured: 0x48 65:6C-6C_6F is read as five bytes and gives the bits for Hello.
The two ways it can fail both name the problem rather than just refusing:
ABC gives “Not hex: 3 hex digits is an odd number, and one byte takes two.”ZZ gives “Not hex: the input has characters outside 0-9 and A-F.”Decoding has one rule of the same kind: the bits must be a whole number of bytes. Measured, seven bits gives “Bit length must be a multiple of 8, and this is 7.” Anything that is not a 0 or a 1 is discarded first, so you can paste bits with spaces, newlines or commas in them and only the digits are counted.
Nothing is uploaded. The encoding and decoding use built-in browser functions running on your device, and the text never leaves it.
TextDecoder and its fatal option. developer.mozilla.orgTextEncoder. developer.mozilla.orgtextarea element. html.spec.whatwg.orgEvery behaviour, byte count and bit string on this page was measured against this tool as it is published, in a browser, on 14 October 2026. Where the page says what the tool does not do, that is a statement about this tool, not about binary conversion in general.
Because UTF-8 uses more than one byte for anything outside the ASCII range. Measured: é is two bytes and sixteen bits, and 🎉 is four bytes and thirty-two bits. The status line gives you the byte count, and the output is grouped in eights so you can count them.
Because the bytes are not valid UTF-8 text, so showing them as text would mean inventing characters. Measured: 11111111 on its own returns FF with a note saying so. The usual causes are data in a single-byte encoding such as Latin-1, or a fragment cut in the middle of a multi-byte character.
Because the HTML standard requires a text box to normalise line breaks to LF in the value a script can read, so a carriage return would be silently converted and you would be shown something other than what you decoded. The tool shows hex instead rather than lie to you. It is the same rule that makes the line-ending option on the encode side necessary.
When the bytes are going somewhere that expects Windows line endings: an HTTP header block, an email message, or a file read by an older Windows tool. Measured on two lines of text, LF gives 3 bytes and CRLF gives 4, with 00001101 added before each 00001010.
Yes. Spaces, commas, colons, semicolons, underscores, hyphens and 0x prefixes are all stripped before parsing. Measured: 0x48 65:6C-6C_6F is read as the five bytes of Hello. An odd number of hex digits or a character outside 0-9 and A-F is refused with a message saying which of the two went wrong.
Because the bits are decoded as bytes, and a partial byte has no meaning. Measured: seven bits gives “Bit length must be a multiple of 8, and this is 7.” Anything that is not a 0 or a 1 is discarded before counting, so spaces and newlines in your bits are fine.
No. It encodes and decodes UTF-8 only, and shows binary, with hex as a fallback for bytes that are not text. That is also the likeliest reason a byte sequence out of an old system will not decode here.
No. Both directions use built-in browser functions running on your device, nothing leaves the page, and nothing is saved, so refreshing loses it.