Text to Binary Converter

A text to binary converter encodes plain text into binary (base-2) representation, where each character is expressed as a sequence of 0s and 1s. It is used by computer science students, educators, developers, and puzzle enthusiasts who need to understand or demonstrate how computers store text at the most fundamental level.

How to Use the Text to Binary Converter

1. Type or paste your text into the input field.
2. Click the convert button.
3. The tool outputs the binary equivalent of each character, typically separated by spaces.
4. To convert back, paste the binary string into the binary-to-text field and run the reverse conversion.
5. Copy the result for use in your project, coursework, or puzzle.

The Formula

Text to binary conversion works through the ASCII (American Standard Code for Information Interchange) or Unicode character encoding standard. Each character in your text has an assigned decimal number; that number is then converted to its 8-bit binary representation.

Steps:

1. Find the ASCII (or Unicode) decimal value of the character. For example, the letter "A" is 65.
2. Convert 65 to binary: 65 = 64 + 1 = 2^6 + 2^0 = 01000001.
3. Pad to 8 bits if necessary (standard byte width).
4. Repeat for each character.

The letter "A" (65) becomes 01000001. The letter "a" (97) becomes 01100001. A space (32) becomes 00100000.

Real-World Example

Convert the word "Hi" to binary.

• "H" has ASCII value 72. 72 in binary is 01001000.
• "i" has ASCII value 105. 105 in binary is 01101001.

Result: 01001000 01101001

To verify, reverse the process: 01001000 = 72 = "H" and 01101001 = 105 = "i". The original text is recovered.

Binary in Computing Contexts

Binary is the native language of digital computers. Every piece of data stored on a computer, whether text, images, audio, or software, ultimately resolves to sequences of binary digits. Understanding binary encoding helps developers debug character encoding issues, understand data storage sizes, and work with low-level protocols. A single ASCII character occupies one byte (8 bits). Extended Unicode characters (such as emoji or characters from non-Latin scripts) may occupy 2 to 4 bytes in UTF-8 encoding, so their binary representations are correspondingly longer.

Frequently Asked Questions

Why are binary values 8 digits long? Eight bits make one byte, which is the standard unit of character storage in ASCII encoding. Eight bits provide 256 possible values (0 to 255), enough to represent the standard ASCII character set and extended characters.

What is the difference between ASCII and Unicode binary? ASCII uses 7 or 8 bits per character and covers 128 to 256 characters. Unicode (encoded as UTF-8, UTF-16, or UTF-32) supports over a million characters and uses variable-length encoding, so non-ASCII characters produce more than 8 binary digits per character.

Can I convert numbers to binary using this tool? If you enter a numeral like "5", the tool converts the character "5" to its ASCII binary value (00110101), not the binary representation of the number five (101). Use a dedicated number base converter if you need the binary value of an integer.

Is binary the same as hex encoding? No. Binary uses base 2 (digits 0 and 1), while hexadecimal uses base 16 (digits 0 to 9 and A to F). Both are ways to represent the same underlying data, and each hex digit corresponds to exactly four binary digits.

A character table you can check by hand

Each character inside ASCII maps to one byte, and the byte has a decimal value that converts to eight binary digits. Four cases cover most of the alphabet by pattern:

| Character | Code point | Decimal | Binary | | A | U+0041 | 65 | 01000001 | | a | U+0061 | 97 | 01100001 | | space | U+0020 | 32 | 00100000 | | 5 | U+0035 | 53 | 00110101 |

Uppercase and lowercase letters sit 32 apart, so a single bit separates them: 01000001 for "A" becomes 01100001 for "a". That one bit is the whole difference, which is why changing case is cheap on ASCII text and why a case-insensitive comparison can be done by masking a bit.

ASCII is not UTF-8

Above code point 127 the two encodings part company, and the gap is where most confusion starts. The tool reads each character with charCodeAt, which returns the UTF-16 code unit, and prints that unit as eight binary digits. The result matches ASCII exactly for the first 128 code points and diverges above them.

| Character | Code point | Tool output, in UTF-16 units | UTF-8 bytes | UTF-8 in binary | | e with acute | U+00E9 | 11101001 | C3 A9 | 11000011 10101001 | | pound sign | U+00A3 | 10100011 | C2 A3 | 11000010 10100011 | | euro sign | U+20AC | 10000010101100 | E2 82 AC | 11100010 10000010 10101100 | | CJK U+4E16 | U+4E16 | 100111000010110 | E4 B8 96 | 11100100 10111000 10010110 | | grinning face | U+1F600 | two units, D83D and DE00 | F0 9F 98 80 | 11110000 10011111 10011000 10000000 |

Two consequences follow. The binary on screen is eight digits per code unit only while the code unit is below 256. And a character outside the basic multilingual plane has no single 16-bit unit, so the tool splits it into a surrogate pair and prints two groups of sixteen digits that correspond to no single character. RFC 3629 defines the UTF-8 form instead: one byte for U+0000 to U+007F, two bytes for U+0080 to U+07FF, three for U+0800 to U+FFFF, and four for U+10000 to U+10FFFF. The leading bits of the first byte carry the length, so a decoder knows from one byte how many follow.

Counting characters, bits and bytes

The tool reports the character count of the input and a bit count equal to eight times that number. The figure describes the tool's own output, eight bits per UTF-16 code unit. It is not the size of the text in UTF-8.

| Text | Characters | Tool bits | UTF-8 bytes | UTF-8 bits | | Hello | 5 | 40 | 5 | 40 | | cafe with an acute e | 4 | 32 | 5 | 40 | | the CJK character U+4E16 | 1 | 8 | 3 | 24 | | grinning face U+1F600 | 1 | 16 | 4 | 32 |

The last three rows are the ones that catch people out. A single character can occupy one to four bytes in UTF-8, and the tool counts UTF-16 code units rather than characters. For sizing a storage column or a network payload, take the UTF-8 column.

Decoding, and what happens to invalid input

The decode direction splits the input on whitespace, parses each group as a base-2 number, and converts the result back to a character. Anything the parser cannot read becomes a question mark rather than an error, so a mistyped group produces a substituted character in the output instead of a warning. A group shorter than eight digits still parses, and one longer than eight parses as a larger number, so the leading zeros carry meaning: 01001000 is "H" at 72, while 00100100 is 36, the dollar sign.

Run the round trip on a short string before encoding a long one. "Hi" becomes 01001000 01101001 and decodes back to "Hi". A single mangled group in the middle of a long run is hard to spot by eye, and the question mark is the only clue the tool gives.

The tool switches between binary, hexadecimal and decimal output for the same encoding. Hexadecimal prints two digits per code unit and decimal prints the code unit value, so "Hi" appears as 48 69 in hex and 72 105 in decimal. Those are the same numbers as the binary column above, written in a shorter base. One hex digit represents exactly four binary digits, which is why hexadecimal is the usual way to inspect byte sequences: two hex digits per byte instead of sixteen binary digits.

Getting UTF-8 bytes instead

When the target is a real byte sequence rather than a teaching aid, the string has to be encoded as UTF-8. TextEncoder does it in one step in a browser or in Node, and the resulting byte values print in binary, hexadecimal or decimal.

| Input | Tool output | UTF-8 bytes in hex | | Hi | 01001000 01101001 | 48 69 | | cafe with an acute e | 01100011 01100001 01100110 11101001 | 63 61 66 C3 A9 | | pound sign then 5 | 10100011 00110101 | C2 A3 35 | | A, then U+1F600, then B | 01000001 1101100000111101 1101111000000000 01000010 | 41 F0 9F 98 80 42 |

The second row is the clearest difference. The tool prints four groups and the UTF-8 form needs five bytes, because the accented letter takes two. The third row shows the same thing at the start of the string: the pound sign becomes two bytes while the digit after it stays at one. Where the two disagree, the UTF-8 column is what a file, a socket or an API actually carries.

A quick check on any string: encode text that is pure ASCII and the two columns match. Encode anything else and the tool's output comes out shorter than the real byte sequence, never longer, because the tool spends exactly one code unit per unit while UTF-8 spends at least one byte per character and more on the ones above code point 127.

Also try these free tools:

• Morse Code Converter
• Base64 Converter
• Number Base Converter