Converting plain text to binary means running a Unicode string through a UTF-8 encoder and printing every resulting byte as exactly eight zero-padded bits, separated by a single ordinary space. Because modern text is Unicode, the encoder may produce one, two, three, or four bytes per visible character depending on which code points appear in the input. The visible output is therefore a sequence of byte groups, not a sequence of one-to-one "character codes," and that distinction matters whenever someone tries to decode the result back into the original string. The encoding itself is handled by the browser's standards-based WHATWG TextEncoder, so the bytes match what every modern application produces when it writes the same string to disk or sends it over the network. A reliable conversion tool makes this byte representation explicit and verifiable, instead of leaving readers to guess whether "A" is one byte, whether "é" is one or two, or whether "😀" should even appear at all. That verifiable, byte-by-byte view is exactly what the Text to Binary Converter produces, with no upload step and no guesswork about which encoding is in play.
Inside the Encoding: What the Byte Groups Mean
Plain text in the modern sense is a Unicode string. When a tool converts that string to binary, it has to commit to two decisions up front: which encoding to use, and how to group the resulting bits. Both decisions affect the output byte-for-byte.
UTF-8 is the encoding of choice on the open web and inside browsers, which is why an encoder that follows the WHATWG standard produces byte sequences that match what operating systems, databases, and protocols actually emit. The grouping rule used here is "exactly eight bits per byte, separated by one ordinary space," a format strict enough to decode unambiguously and loose enough to read as ordinary text. The MDN reference for TextEncoder documents the exact behavior the converter relies on.
A tool that respects those decisions will encode the capital letter "A" (U+0041) as the single byte 01000001. It will encode "é" (U+00E9) as the two bytes 11000011 10101001. It will encode "€" (U+20AC) as 11100010 10000010 10101100. And it will encode the grinning face emoji 😀 (U+1F600) as 11110000 10011111 10011000 10000000 — four bytes, none of them an ASCII printable character. The Text to Binary Converter performs this work locally, so input and output stay in the current tab and are not transmitted anywhere.
Convert Plain Text to Binary in Your Browser
The browser-based workflow removes the need to install a library, run a script, or copy your string into a remote service. To use the Text to Binary Converter, follow these steps:
- Open the Text to Binary Converter and choose Text to UTF-8 binary from the mode selector. If you want to turn binary back into text instead, pick UTF-8 binary to text.
- Type or paste your plain text into the input area. For the encoder, ordinary text — including letters with accents, currency symbols, CJK characters, and emoji — is accepted as long as the input stays within the 20,000 UTF-16 code unit budget. For the decoder, the serialized input is capped at 180,000 characters of strict eight-bit groups separated by one ordinary space.
- Click Convert. The tool runs the encoder, prints one eight-bit group per byte separated by a single space, and reports the total byte count so you can sanity-check the result against the input.
- Review the output. If a line appears wider than expected or a character seems to be missing, the most common cause is a rich-text paste that has already collapsed spaces; paste again as plain text.
- Copy the binary string into a destination that preserves ordinary spaces and line breaks exactly. Plain text editors, code blocks, and terminal buffers are safe; chat clients and rich-text editors often are not.
For the reverse direction, paste groups of exactly eight 0s and 1s separated by one ordinary space — and nothing else, since the decoder rejects commas, "0b" prefixes, tabs, multiple spaces, leading or trailing whitespace, and any character other than 0 or 1 — and click Convert. The decoder uses fatal UTF-8 validation, so a structurally well-grouped sequence that still contains invalid bytes will fail with an explicit error rather than silently substituting the Unicode replacement character.
Byte Width Varies by Character
A common source of confusion is the assumption that one character maps to one byte. Under UTF-8, the byte count depends on the character's Unicode code point range, and the converter reflects that directly in its output. The table below summarizes the four possible widths and gives a representative example for each.
| Character type | Byte count | Example | UTF-8 byte sequence |
|---|---|---|---|
| Standard ASCII letters and digits | 1 byte | A | 01000001 |
| Latin letters with accents (U+0080 to U+07FF) | 2 bytes | é | 11000011 10101001 |
| Common symbols and most CJK characters (U+0800 to U+FFFF) | 3 bytes | € | 11100010 10000010 10101100 |
| Supplementary plane emoji and rare scripts (U+10000 and above) | 4 bytes | 😀 | 11110000 10011111 10011000 10000000 |
This is why a 10-character string that contains one emoji and one accented letter produces 14 byte groups, not 10. Anyone who needs to know "how many bytes is this string?" can count groups in the converter's output directly instead of estimating from the visible character count. The reference patterns for each width are summarized in the Binary to Text cheat sheet, which pairs common bit patterns with their ASCII equivalents.
Why Decoding Sometimes Fails
The strict eight-bit grouping rule is not a stylistic choice. The decoder operates on bytes, so each group must contain exactly eight binary digits. Anything else — seven-bit groups, nine-bit groups, leading whitespace, a "0b" prefix, commas, tabs, or multiple spaces between groups — is rejected outright. The strictness is what makes the round trip predictable.
Two practical pitfalls deserve attention. First, a rich-text paste breaks spacing. Chat clients, word processors, and many web forms collapse runs of spaces or insert soft line breaks, and decoding a string that has already been mangled by such a paste will fail with a grouping error. The fix is to copy from a source that preserves whitespace, or to use a plain-text intermediary. Second, well-grouped bytes can still be invalid text. UTF-8 has structural rules that go beyond byte width: a leading byte without the right continuation, an overlong sequence, an unpaired surrogate half, or a code point outside the valid range will all cause the decoder to fail. The Text to Binary Converter uses the fatal mode of the WHATWG TextDecoder, documented on MDN, so malformed input produces a clear error instead of a silent replacement character. This matters for protocol, source-code, and forensic work, where a false round trip is worse than an honest failure.
What Plain Text to Binary Is Not
The output of this conversion contains exactly the same information as the original string — no compression, no secrecy, no integrity check, no password protection. Anyone with the byte sequence and a UTF-8 decoder can recover the original text, which is why binary is sometimes mistaken for encryption even though it offers none of the confidentiality properties that encryption implies.
It is also worth knowing what the tool deliberately does not do, because some adjacent tasks look similar but require different machinery. It does not render numeric binary values, machine instructions, or raw file contents. It does not parse hexadecimal, Base64, Morse code, or any custom legacy character set. It does not split supplementary characters into JavaScript UTF-16 code units, and it does not interpret each Unicode scalar value as if it were always one byte.
For those tasks, neighboring encoding tools are the right destination: the Base64 Encode / Decode utility for transport-safe ASCII representations, the Hex to Text Converter for hexadecimal byte strings, and the Morse Code Translator for audio or signal use. The Text to Binary Converter stays focused on producing and consuming explicit eight-bit UTF-8 byte groups so that every byte in the original string is visible, named, and verifiable against the TextDecoder specification rather than against how a font happens to draw the output.