Binary and Hex Translator
- Choose the direction: text to binary or binary to text.
- Paste the content. When converting from binary, spaces and other separators are ignored — only the 0s and 1s count.
- The result appears as you type.
The text is first converted to UTF-8 bytes, and each byte is written as 8 binary digits, padded with leading zeros.
Characters from the basic Latin alphabet take 1 byte and produce 8 digits. Accented letters take 2 bytes, meaning 16 digits. Emoji reach 4 bytes and 32 digits.
That is why "ola" produces 24 digits while "olá" produces 32: the á alone counts as two characters in bytes.
When converting from binary to text, the number of digits must be a multiple of 8. With bits missing or left over there is no way to form complete bytes, and the conversion is refused.
Even with the right length, the sequence must form valid UTF-8. Decoding runs in strict mode, so bytes that do not make a legitimate character raise an error instead of returning that diamond with a question mark.
Refusing is deliberate: warning that the input is corrupted is better than handing back silently wrong text.
- A university exercise or a study of data representation.
- Manually checking the contents of a buffer while debugging.
- Understanding why accented text takes more bytes than the character count suggests.
- Solving a CTF challenge or a puzzle that encodes its message in binary.
- Pick a direction: text to hexadecimal, or hexadecimal to text.
- Paste your content. When converting from hex, spaces, line breaks and prefixes are ignored — only hex digits count.
- The result updates as you type.
The text is encoded to UTF-8 bytes, and each byte is written as two uppercase hexadecimal digits separated by a space.
Two digits represent exactly one byte because each hex digit carries 4 bits. That direct mapping is why hexadecimal is the standard notation for inspecting binary data.
Basic Latin characters take 1 byte, accented letters take 2, and emoji can take 4. That is why the number of pairs does not match the number of characters in accented text.
Converting from hex requires an even number of digits — each byte needs two. A single leftover digit cannot form a byte, so the conversion is refused.
Even with an even count, the bytes must form valid UTF-8. Decoding runs in strict mode, so an invalid sequence raises an error instead of returning the replacement character.
Refusing is deliberate: silently handing back corrupted text would be worse than reporting that the input is wrong.
- Inspect what a field actually contains while debugging.
- Check the encoding of text that shows up with strange characters.
- Convert a hex sequence found in a log or a binary dump.
- Solve a CTF challenge or a data representation exercise.
Frequently asked questions
When converting from binary to text, no: any character other than 0 or 1 is discarded first. What matters is that the digit total is a multiple of 8.
Because the count stopped being a multiple of 8 and complete bytes can no longer be formed. A single missing bit invalidates the whole sequence.
Because in UTF-8 it takes 2 bytes, and each byte becomes 8 digits. Emoji can take 4 bytes and produce 32 digits.
No. It is just another representation of the same bytes, fully reversible and with no key. It protects nothing.
No. The conversion happens in your browser.
Not when converting from hex to text. Anything that is not a hex digit is stripped first, so spaces, line breaks and prefixes can stay.
Because the digit count stopped being even and the last byte became incomplete. Every byte needs exactly two digits.
Because it takes 2 bytes in UTF-8, and each byte becomes a pair of digits. Emoji can take 4 bytes and produce 4 pairs.
Both represent bytes as text. Hexadecimal uses 16 symbols and doubles the size; Base64 uses 64 symbols and grows by about a third. Hex is easier to read for inspection, Base64 is more compact for transport.
No. The conversion happens in your browser.