Text to Binary Converter: Encode & Decode Binary Online

From 5-Hole Paper Tape to 1.1 Million Unicode Characters: The 160-Year History of Text in Binary

In 1870, Émile Baudot developed a character encoding for telegraph machines using 5-hole paper tape. Each hole pattern represented one letter: 5 binary positions, 32 possible combinations, enough for uppercase Latin letters plus a few control codes. This was the first standardized text-to-binary encoding system.

In 1963, the American Standards Association ratified ASCII (American Standard Code for Information Interchange) — a 7-bit encoding that expanded the character set to 128 code points: uppercase and lowercase Latin letters, digits 0–9, punctuation, and 33 non-printable control characters (including carriage return, line feed, tab, and the now-infamous bell character). ASCII's design decision to use 7 bits rather than 8 was a storage optimization — magnetic tape was expensive — that left the 8th bit unused and created 60 years of encoding fragmentation as different vendors used that extra bit differently.

In 1991, the Unicode Consortium published Unicode 1.0, aiming to unify every character system in the world into a single code point space. Today, Unicode 15.1 defines 149,813 characters across 161 scripts — from ancient Cuneiform to emoji, from mathematical symbols to playing card suits.

In 1993, Ken Thompson and Rob Pike designed UTF-8 — a variable-width encoding that represents Unicode code points as 1 to 4 bytes, with the critical property of backward compatibility with ASCII. Any ASCII text file is a valid UTF-8 file. UTF-8 is now the dominant encoding on the web: per the W3Techs Web Technology Survey (April 2026), 98.3% of all websites use UTF-8 as their character encoding.

Understanding how each character you type maps to binary is not esoteric knowledge — it is the foundation of network protocols, cryptographic hashing, database storage, file formats, and every debugging session that involves inspecting raw bytes.

The Two-Step Process: Code Points Then Bytes

Text-to-binary conversion requires understanding two distinct concepts that are often conflated: character encoding standards (which number to assign each character) and encoding schemes (how to serialize those numbers as bytes).

'H'  →  U+0048  (decimal: 72)
'e'  →  U+0065  (decimal: 101)
'l'  →  U+006C  (decimal: 108)
'!'  →  U+0021  (decimal: 33)
'é'  →  U+00E9  (decimal: 233)
'中' →  U+4E2D  (decimal: 20013)
'😀' →  U+1F600 (decimal: 128512)

'H'  →  code point 72  →  1 byte: [0x48]        →  01001000
'é'  →  code point 233 →  2 bytes: [0xC3, 0xA9]  →  11000011 10101001
'中' →  code point 20013 → 3 bytes: [0xE4,0xB8,0xAD] → 11100100 10111000 10101101
'😀' →  code point 128512 → 4 bytes: [0xF0,0x9F,0x98,0x80] → 11110000 10011111 10011000 10000000

The critical insight: "text to binary" is not a single operation. The binary representation of a character depends entirely on the encoding used. A naïve tool that treats each character as a single byte will silently produce wrong output for any non-ASCII character. A correct tool applies UTF-8 encoding before converting to binary.

ASCII Binary Reference: The 128 Characters You Use Every Day

ASCII's 7-bit design means printable characters occupy code points 32–126. Control characters (0–31 and 127) are non-printable. Here is the complete reference for the printable ASCII range — the characters whose binary representations you will encounter most frequently in debugging and protocol analysis:

UTF-8 Multi-Byte Encoding: How It Actually Works

UTF-8's variable-width design uses a clever self-synchronizing byte structure. You can identify the role of any byte by its leading bits — no context needed:

The 10xxxxxx continuation byte pattern is why UTF-8 is self-synchronizing: if you drop into a byte stream mid-sequence, you can identify continuation bytes (starting with 10) and skip backward to the sequence start byte. This property is absent in older fixed-width encodings like UTF-16 and UTF-32, which is one of the reasons UTF-8 dominated.

Working Through 'é' (U+00E9) Step by Step

Code point: U+00E9 = 233 decimal = 0xE9

Step 1: Identify byte count.
  233 is in range U+0080–U+07FF → 2 bytes
  Pattern: 110xxxxx 10xxxxxx (11 data bits available)

Step 2: Convert 233 to binary:
  233 = 11101001 (8 bits)

Step 3: Fit bits into pattern (11 data bits, use right-to-right):
  11101001 → 00011101001 (pad to 11 bits)
  Split: 00011 | 101001
  First byte:  110 + 00011 = 11000011 = 0xC3
  Second byte: 10  + 101001 = 10101001 = 0xA9

Result: 0xC3 0xA9 → binary: 11000011 10101001

Text to Binary: "Hello, World!" Character by Character

All characters in "Hello, World!" are ASCII (U+0000–U+007F), so each is exactly 1 byte in UTF-8:

Full binary output (space-separated by character):

01001000 01100101 01101100 01101100 01101111 00101100 00100000 01010111 01101111 01110010 01101100 01100100 00100001

Text to Binary in Code: JavaScript, Python, Go

JavaScript — Browser and Node.js

// Text to binary (UTF-8 aware):
function textToBinary(text) {
  const encoder = new TextEncoder() // Always UTF-8
  const bytes = encoder.encode(text)
  return [...bytes]
    .map(byte => byte.toString(2).padStart(8, '0'))
    .join(' ')
}

console.log(textToBinary('Hello'))
// => "01001000 01100101 01101100 01101100 01101111"

console.log(textToBinary('é'))
// => "11000011 10101001"  (2 bytes for U+00E9)

console.log(textToBinary('😀'))
// => "11110000 10011111 10011000 10000000"  (4 bytes)

// Binary back to text:
function binaryToText(binaryString) {
  const bytes = binaryString.trim().split(/s+/)
    .map(b => parseInt(b, 2))
  const decoder = new TextDecoder('utf-8')
  return decoder.decode(new Uint8Array(bytes))
}

console.log(binaryToText('01001000 01100101 01101100 01101100 01101111'))
// => "Hello"

Python

def text_to_binary(text: str, encoding: str = 'utf-8') -> str:
    """Convert text to space-separated binary string."""
    return ' '.join(format(byte, '08b') for byte in text.encode(encoding))

def binary_to_text(binary_string: str, encoding: str = 'utf-8') -> str:
    """Convert space-separated binary string back to text."""
    byte_strings = binary_string.strip().split()
    byte_values = [int(b, 2) for b in byte_strings]
    return bytes(byte_values).decode(encoding)

# Examples:
print(text_to_binary('Hello'))
# 01001000 01100101 01101100 01101100 01101111

print(text_to_binary('é'))
# 11000011 10101001

print(text_to_binary('中'))
# 11100100 10111000 10101101

# Round-trip verification:
original = 'Hello, World! 🌍'
binary = text_to_binary(original)
recovered = binary_to_text(binary)
assert original == recovered, "Round-trip failed"
print(f"Round-trip verified: {len(binary.split())} bytes")

Go

package main

import (
    "fmt"
    "strconv"
    "strings"
)

func textToBinary(s string) string {
    // Go strings are UTF-8 byte slices — iterate bytes directly
    parts := make([]string, 0, len(s))
    for _, b := range []byte(s) {
        parts = append(parts, fmt.Sprintf("%08b", b))
    }
    return strings.Join(parts, " ")
}

func binaryToText(binary string) (string, error) {
    parts := strings.Fields(binary)
    bytes := make([]byte, len(parts))
    for i, part := range parts {
        val, err := strconv.ParseUint(part, 2, 8)
        if err != nil {
            return "", fmt.Errorf("invalid binary at position %d: %w", i, err)
        }
        bytes[i] = byte(val)
    }
    return string(bytes), nil
}

func main() {
    fmt.Println(textToBinary("Hello"))
    // 01001000 01100101 01101100 01101100 01101111

    text, _ := binaryToText("01001000 01100101 01101100 01101100 01101111")
    fmt.Println(text) // Hello
}

Four Common Mistakes in Text-to-Binary Conversion

1. Treating Characters as Single Bytes

The most common error: using charCodeAt() in JavaScript and treating the result as a complete UTF-8 byte. 'é'.charCodeAt(0) returns 233 — the Unicode code point — not the UTF-8 encoding. For ASCII characters this coincidentally produces the right answer, so the bug hides until a non-ASCII character appears. Always use TextEncoder or equivalent.

2. Omitting the Leading Zero Pad

The space character (decimal 32) in binary is 00100000. Without the leading zeros, it becomes 100000 — only 6 bits. This makes it impossible to reconstruct the original byte stream unambiguously. Always pad to 8 bits: .padStart(8, '0') in JS, format(byte, '08b') in Python.

3. Confusing UTF-16 Surrogate Pairs

JavaScript strings are UTF-16 internally. Characters above U+FFFF (like emoji) are stored as two 16-bit "surrogate pairs." '😀'.length returns 2 in JavaScript, not 1, because the engine counts UTF-16 code units. Using TextEncoder correctly handles this — it converts the surrogate pair to the correct 4-byte UTF-8 sequence. Processing charCodeAt() on each character position produces surrogates, not valid UTF-8.

4. Incorrect Separator Assumptions During Decode

Binary strings are often space-separated (one 8-bit group per character) but sometimes presented as continuous strings with no separators. When decoding, you must know the format: 01001000... (continuous) vs 01001000 01100101... (space-separated). Continuous binary should be split into 8-character chunks: binaryStr.match(/.{1,8}/g).

Real-World Applications of Binary Text Representation

Understanding text-as-binary is not an academic exercise. These are the actual software contexts where you will encounter and need to manipulate binary text:

Network Protocol Debugging

TCP/IP packets carry bytes, not characters. Protocol analyzers like Wireshark display packet payloads in hexadecimal — reading HTTP headers, WebSocket frames, or DNS records at the byte level requires knowing which byte sequences correspond to which ASCII characters. A GET request starts with bytes 0x47 0x45 0x54 (71, 69, 84 — 'G', 'E', 'T' in ASCII).

Cryptographic Hash Verification

Cryptographic functions like SHA-256 operate on byte arrays, not strings. The hash of "Hello" and the hash of "Hello" (with a trailing newline) differ — which is why encoding matters. A security audit of hash-based verification code requires tracing exactly what bytes were fed to the hash function, which means tracing the UTF-8 encoding of the input string. See BytePane's hash functions explained guide for the full picture.

File Format Parsing

Binary file formats begin with "magic bytes" — fixed byte sequences that identify the file type. PDF files start with 25 50 44 46 hex (%PDF in ASCII). PNG files start with 89 50 4E 47 (‰PNG). Validating file uploads at the byte level rather than trusting file extensions is a security best practice — and it requires knowing the binary representation of ASCII characters.

Base64 Encoding

Base64 operates on the byte-level representation of text: it takes the UTF-8 bytes of a string and re-encodes them using only 64 ASCII-safe characters. "Hello" encodes to "SGVsbG8=" in Base64 — directly from the bytes 72, 101, 108, 108, 111. Understanding the UTF-8 byte layer clarifies why the same string in different encodings produces different Base64 output. For Base64 encoding/decoding tools and mechanics, see BytePane's Base64 encoding guide.

Embedded Systems and Hardware Registers

Microcontroller communication protocols (UART, SPI, I²C) transmit bytes. Sending a string over a serial port means writing each character's byte value to a hardware register. Embedded developers work in binary and hexadecimal constantly — knowing that ASCII 'A' is 0x41 is as fundamental as knowing that 'A' is the first letter.

Binary vs Hexadecimal vs Decimal: Three Views of the Same Byte

Binary, hexadecimal, and decimal are three notations for the same underlying byte values. Each has its use case:

The conversion between binary and hexadecimal is exact: every 4 binary bits correspond to one hex digit. 01000001 splits as 0100 (= 4 = hex 4) + 0001 (= 1 = hex 1) = 0x41. This grouping is why developers reach for hex over binary for most debugging — it is 4× more compact while preserving the exact bit pattern. If you need to convert between hexadecimal and decimal or binary programmatically, BytePane's hex to decimal converter guide covers the full conversion math.

Frequently Asked Questions