Zum Hauptinhalt springen
ToolsByUs

Text to Binary

This converter shows the UTF-8 bytes behind any text as 8-bit binary groups, and toggles the other way just as happily. ASCII characters take one byte, emoji take four; decoding rejects input that is not a multiple of 8 bits or not valid UTF-8. Everything runs locally in your browser.

Nur lokal

Die Oberfläche dieses Tools ist auf Englisch.

Die folgende Anleitung ist nur auf Englisch verfügbar.

Text to Binary explained

There is no such thing as the binary of a letter: bits describe bytes, and bytes depend on the encoding. This tool shows the encoding the web settled on — UTF-8, per RFC 3629, in which every character from a to 🙂 is one to four bytes, rendered as 8-bit groups.

The encoding is self-describing: the first byte announces the length. A byte starting 0 is one byte of ASCII; 110 starts two; 1110 starts three; 11110 starts four; every continuation byte starts 10. Memorise that one rule and the output becomes readable.

The direction toggle decodes back: paste bits, get text. Decode is deliberately strict — a bit count that is not a whole number of bytes, or bytes that break UTF-8's continuation rules, is rejected rather than decoded into replacement characters. The conversion happens in this tab; nothing is uploaded.

Raw bits are for seeing; when those bytes have to travel through a text-only channel, base64 is the standard wrapper, and the Base64 explained guide explains why it was designed that way.

Binary is verbose — eight characters per byte — and the Base64 vs hex comparison shows why hexadecimal usually wins on paper and how the two notations relate.

How text becomes bits

The converter hands your text to the browser's own TextEncoder, which emits UTF-8 bytes directly. That matters for emoji: JavaScript strings store 🙂 as two surrogate halves, but the encoder works on code points, so it produces one four-byte sequence. Each byte is padded to exactly eight bits and grouped — eight bytes per line by default.

  • Encode: the string becomes UTF-8 bytes via TextEncoder — no BOM, no locale dependence.
  • Render: each byte is written as 8 bits, zero-padded — 0x48 is 01001000, not 1001000.
  • Group: bytes are separated by spaces, lines by newlines, at the grouping you choose.
  • Decode: the reverse path strips every non-01 character, reassembles bytes, and decodes strict UTF-8.

Reading the output: the lead byte tells you the length

UTF-8's design goal was ASCII compatibility, and the patterns show it. ASCII keeps its familiar one-byte codes — 01000001 is A in both — while longer sequences are built from lead and continuation bytes in fixed patterns:

  • é (U+00E9) is 11000011 10101001 — a two-byte lead and one continuation.
  • 🙂 (U+1F642) is 11110000 10011111 10011001 10000010 — the four-byte form.
  • A 10-prefixed byte in isolation is a continuation with no lead — the classic corruption signature.
Code point rangeBytesPattern
U+0000 – U+007F (ASCII)10xxxxxxx
U+0080 – U+07FF2110xxxxx 10xxxxxx
U+0800 – U+FFFF31110xxxx 10xxxxxx 10xxxxxx
U+10000 – U+10FFFF (emoji live here)411110xxx 10xxxxxx 10xxxxxx 10xxxxxx

What decode refuses, and why

Decode accepts messy formatting on purpose: spaces, commas and line breaks are stripped before parsing. Two rejections remain: a bit count that is not a multiple of 8 cannot be split into bytes — the error reports the exact count — and bytes that break the patterns above are refused by a fatal UTF-8 decoder rather than replaced with U+FFFD.

That second refusal saves afternoons: a lenient decoder turns a broken sequence into a string of � marks that look plausible and are silently wrong. Refusing means the cause gets investigated instead of shipped.

Where 8-bit groups show up elsewhere

Networking calls a byte an octet: an IPv4 address is four of these groups in decimal, and a subnet mask is a run of 1s followed by 0s across the same 32 bits. The binary view also explains mojibake — é in UTF-8 is 11000011 10101001, and misread as Latin-1 those bytes are à and ©, the é pattern you see when UTF-8 is decoded with the wrong encoding. Seeing the bytes is the fastest diagnosis.

Frequently asked questions

Does converting text to binary upload anything?

No. The bytes come from the browser's built-in TextEncoder, decoding from its TextDecoder — both in this tab; no request is made during a conversion, which DevTools' Network panel confirms. The page is served with connect-src 'self', so the browser would refuse any outbound call a script attempted.

Is a character's binary form always the same?

No — it depends on the encoding. é is two bytes (11000011 10101001) in UTF-8, one byte (11101001) in Latin-1. This tool always uses UTF-8, the web's standard per RFC 3629, matching what browsers transmit and what most file formats assume.

How many bits does an emoji take in UTF-8?

Most take four bytes — 32 bits — because they sit above U+10000, the range UTF-8 encodes with a 11110xxx lead byte and three continuations. A few older symbols such as ☺ live below U+10000 and take three. ASCII is the other extreme: one byte per character.

Why was my decode rejected as not a multiple of 8?

Bits only become bytes in complete groups of eight; a remainder means something is missing or extra — a truncated paste, a dropped line, a stray digit. The error states the exact bit count. Formatting is never the cause: spaces and line breaks are stripped before the count.

What does the invalid UTF-8 error on decode mean?

The bytes broke UTF-8's contract: a continuation byte with no lead, a multi-byte sequence cut off at the end, or an impossible pattern. The tool decodes fatally — refusing rather than substituting U+FFFD marks — because silently mojibake'd output is worse than an error. Data that was never UTF-8, such as Latin-1 text, trips this by design.

Can I paste binary with spaces or line breaks?

Yes. Every character that is not 0 or 1 is stripped before parsing, so spaced groups, one-byte-per-line dumps and comma-separated lists all parse. If the digits themselves are damaged, the strict decode catches that — formatting is forgiven, data is not.

ToolsByUs team · How we check our tools