Convert plain text to binary code and binary back to text in real-time — byte by byte, UTF-8, 100% in your browser.
How a byte value is computed, how negative numbers are represented, and why one accented letter needs more than 8 bits.
Binary is a positional base-2 system: inside a byte each bit carries a power of two, with weights 128, 64, 32, 16, 8, 4, 2 and 1 from left to right. That is why 01000001 reads as 64 + 1 = 65 in decimal, which is the letter "A" in the ASCII table and 0x41 in hexadecimal. Converting to hex is mechanical because every 4-bit group (a nibble) maps to one hex digit: 0100 is 4 and 0001 is 1. A single byte spans 256 values (0-255) and exactly two hex digits, which is why memory dumps, CSS colors (#FF8800) and MAC addresses are written in hexadecimal instead of binary.
Signed integers are stored in two’s complement, where the most significant bit carries a negative weight of -2^(N-1). In an 8-bit integer, 11111111 is not 255 but -1, and the range runs from -128 to 127. To negate a value, invert every bit and add 1: 00000101 (5) becomes 11111010 + 1 = 11111011 (-5). The scheme removes the duplicate negative zero and lets an ALU subtract using the same adder circuit it uses to add. It also explains the classic overflow bug: adding 1 to 01111111 (127) yields 10000000, which reads back as -128. The byte 0xFF means 255 unsigned and -1 signed; only the declared type decides.
ASCII defines only 128 code points in 7 bits, so everything else relies on UTF-8, a variable-length encoding that announces its length in the leading bits: 0xxxxxxx for one byte, 110xxxxx 10xxxxxx for two, 1110xxxx for three and 11110xxx for four. "é" (U+00E9) becomes 11000011 10101001 (0xC3 0xA9), the ideograph 中 (U+4E2D) takes three bytes, and an emoji such as 😀 (U+1F600) takes four. Do not confuse characters with bytes: in JavaScript "😀".length returns 2 because strings are UTF-16 and the emoji is stored as a surrogate pair, while its UTF-8 binary form is 32 bits long.
Usually because the digit count is not a multiple of 8. If you copied 7-bit ASCII groups or a leading zero was dropped, every byte after that point is misaligned. Also check for stray characters that are neither 0 nor 1, and when the text contained accents or emoji, make sure all 2 to 4 UTF-8 bytes of each character are present.
That is mojibake: the two UTF-8 bytes of "é" (0xC3 0xA9) are being read as two separate Latin-1 characters, Ã and ©. The binary is correct; the encoding declared on the decoding side is not. Force UTF-8 at the destination, for example with <meta charset="utf-8"> or charset=utf-8 in the Content-Type header.
Not for UTF-8: its byte sequence is fixed by the standard and reads identically on x86, ARM or any other architecture, which is why it needs no BOM. It does matter for UTF-16 and UTF-32, where FE FF or FF FE marks the order, and for multi-byte integers: 0x41424344 is stored as 44 43 42 41 on little-endian x86 and as 41 42 43 44 in big-endian network order.