To describe how to convert text to binary numbers, treat each UTF-8 byte of your string as exactly eight zero-padded bits and join those eight-bit groups with a single ordinary space. In this model "A" is one byte (01000001), the accented letter "é" is two bytes (11000011 10101001), the euro sign "€" is three bytes (11100010 10000010 10101100), and the emoji "😀" is four bytes (11110000 10011111 10011000 10000000). The mapping is not "one character equals eight bits," because a Unicode character can occupy one to four UTF-8 bytes depending on where its code point sits. The output is therefore a sequence of complete, named bytes—the same bytes a system stores on disk—rendered in base 2 and separated so each group is unambiguous. Reversing the operation means parsing exactly eight binary digits per group with one space between them, then feeding those bytes to a strict UTF-8 decoder; any malformed sequence produces a clear fatal error rather than being swapped for the Unicode replacement character U+FFFD. Understanding that variable-width byte representation is the difference between describing a real text-to-binary conversion and merely restating ASCII digits.
Most people meet binary for the first time through classroom charts that pair each letter with a tidy row of eight 0s and 1s. That picture is fine for the English alphabet and the digits 0 through 9, but it breaks down the moment a string contains an accent mark, a non-Latin script, or an emoji. Underneath every operating system, web request, and source file sits the UTF-8 byte sequence documented in the WHATWG Encoding Standard. A byte is always exactly eight bits, and the count of bytes per character is set by the Unicode code point, not by a fixed rule of "one character, one byte." The Text to Binary Converter simply surfaces that byte sequence as readable text so each byte is countable, copyable, and verifiable.
Text Becomes Bytes, Not Single Digits
The conversion runs on bytes, not on letters, and bytes follow a strict, documented schema. ASCII characters—covering the English alphabet, digits, and common punctuation—live at U+0000 through U+007F in the Unicode Standard and always encode as a single byte whose high bit is zero. Characters in the next range, including accented Latin letters, Greek, Cyrillic, Arabic, and Hebrew, take two bytes with leading bits 110 and 10 in well-defined positions. Most characters of the Basic Multilingual Plane, including CJK ideographs and common currency symbols, occupy three bytes. Supplementary characters, which include most emoji and rare historic scripts, take four bytes and live above U+FFFF.
| Code-point range | Bytes per character | Typical examples |
|---|---|---|
| U+0000 to U+007F | 1 byte | "A", "7", "?" |
| U+0080 to U+07FF | 2 bytes | "é", "ñ", "Ω" |
| U+0800 to U+FFFF (BMP, excluding surrogates) | 3 bytes | "€", "中", "★" |
| U+10000 to U+10FFFF (supplementary) | 4 bytes | "😀", "𝕊", ancient scripts |
The byte counts in this table come from the WHATWG Encoding Standard and apply to every compliant UTF-8 implementation; the exact sequence produced for a specific input is what the converter displays after you press Convert.
Converting Text to Binary Step by Step
The Text to Binary Converter applies this scheme through three browser-side operations. Everything runs locally through the standard TextEncoder for encoding and a strict TextDecoder for the reverse direction, with no network upload of your input.
- Open the Text to Binary Converter and choose the Text to UTF-8 binary mode.
- Type or paste the string to convert into the input field. The encoder accepts strings up to 20,000 UTF-16 code units, enough for lengthy paragraphs or several pages of plain text.
- Select Convert and review the byte count shown beneath the output. Every UTF-8 byte appears as exactly eight zero-padded bits separated by one ASCII space.
- Copy the result to your clipboard for use in code, documentation, an exercise sheet, or another tab.
A small worked example makes the byte structure obvious. Take the word "Hi", which is two ASCII characters.
Step 1 — code points: "H" is U+0048 and "i" is U+0069 in the Unicode Standard.
Step 2 — UTF-8 bytes: Both characters sit inside the ASCII range, so each encodes as a single byte: 0x48 and 0x69.
Step 3 — base-2 form, eight digits each: 0x48 = 01001000 and 0x69 = 01101001.
Step 4 — join with one space: 01001000 01101001, exactly two bytes for two characters.
If you replace "Hi" with "Hé", the second character needs two bytes (0xC3 0xA9) and the output grows from two bytes to three. That visible growth is the proof the converter is rendering bytes, not a per-character base-2 view.
Why Every Group Must Be Exactly Eight Bits
The decoder enforces strict grouping because anything looser makes the result ambiguous. Eight-bit groups correspond to one byte, which is the smallest unit a UTF-8 decoder consumes. If a group has seven or nine digits the parser cannot tell which side the missing or extra bit belongs to; if groups are separated by tabs, commas, or runs of multiple spaces, the tokenizer fails before the decoder sees any bytes. The converter therefore accepts only the regular language of [01]{8}( [01]{8})*, with no leading or trailing whitespace and no prefixes such as "0b".
The same strictness applies on the decoding side. Malformed sequences—overlong encodings, lone continuation bytes, surrogate halves used in isolation, code points outside the Unicode range—do not get replaced with U+FFFD. Instead the fatal UTF-8 decoder throws a clear error so you can locate and fix the problem. This fatal validation is what makes the round trip reliable for checking exact UTF-8 strings rather than a "looks roughly right" approximation. The reverse direction explained in the same plain-English style lives in the binary-to-text conversion guide.
Limits, Errors, and What Binary Text Cannot Do
Two numeric budgets bound the converter and matter once an input grows large. Encoding accepts strings up to 20,000 UTF-16 code units; decoding accepts serialized input up to 180,000 characters (the digit count plus separators). Inputs past those budgets are rejected before any conversion is attempted so the tool does not silently truncate or guess.
| Direction | Maximum input | Hard requirement |
|---|---|---|
| Encode text to UTF-8 binary | 20,000 UTF-16 code units | Any Unicode string; byte count varies by code point |
| Decode UTF-8 binary to text | 180,000 characters of serialized input | Groups of exactly eight binary digits, one ASCII space, no surrounding whitespace |
Binary output is also not a substitute for several neighbouring tasks. The converter does not interpret binary as the base-2 representation of an integer, does not parse Morse code, does not execute machine instructions on the bytes, and does not recognize hexadecimal or Base64 formats. It is also not encryption: anyone who reads the output can recover the original text because binary is a reversible representation of the same information. The product documentation explicitly warns that binary offers no confidentiality, authentication, integrity, or compression. For secrecy use a real cipher with a key; if the real goal is hex, code points, or authenticated encryption, the dedicated encoding tools handle each case with its own format rules.
Handling the Output After You Copy It
Binary output is plain text with ordinary spaces, which makes it fragile in places that do not preserve whitespace exactly. Chat applications in particular often collapse runs of spaces, treat them as soft line breaks, or insert zero-width characters when you paste. Once that happens, the strict decoder cannot parse the groups and the round trip fails even though the underlying bytes are unchanged. Sending the result through email, a fenced code block in a Markdown document, a GitHub gist, or a plain .txt attachment is usually safe; pasting straight into a rich-text editor or a chat box is not.
For protocol work, source-code reviews, or forensics, the responsible habit is to verify the actual byte sequence against the destination system's specification rather than trusting how a font or preview renders the digits on screen. The Text to Binary Converter only shows bytes; whether the next program reads those bytes back correctly is a property of that program and of the transport in between, not of the converter itself.