Binary ⇄ Text Converter

There is no such thing as "the binary" of a character

Converting text to binary requires choosing an encoding first, and the choice changes every byte — including for plain ASCII:

Not one of them matches. Even A is one byte in UTF-8 and two in UTF-16. And neither encoding is smaller in general — UTF-8 is compact for Latin text and costs three bytes for Chinese where UTF-16 costs two. Which is better depends entirely on what you are writing.

This converter uses UTF-8, which is the right default for anything going near the web. But "the binary of é" is a question with more than one correct answer, and a tool that does not tell you which encoding it used has left something out.

And "how long is this text" has four answers

😀 is a single character and a single code point, U+1F600. JavaScript stores strings as UTF-16, and anything above U+FFFF needs two units — a surrogate pair, U+D83D U+DE00 — so "😀".length is 2 rather than 1. Slice at one unit and you get half a surrogate pair, which is why naive truncation produces those little replacement squares.

A family emoji is worse, because it is several code points joined by invisible zero-width characters:

So for a string as short as Hi 😀 the question "how long is this" has four defensible answers: 56 bits in utf-8, 80 bits in utf-16, 5 javascript string length, 4 characters a reader sees. Any tool reporting a single number is choosing among those silently.

That matters wherever a limit is enforced — a 280-character post, a database column measured in bytes, an SMS billed per segment. On plain ASCII all the character counts agree, which is precisely why the distinction goes unnoticed: Hello is 5 units, 5 code points and 5 characters, and only the byte counts differ. The first emoji is where that quietly stops being true.