Online Text Tools Online Text Tools
← Back to Blog Aug 05, 2026 8 min read

Demystifying Character Encodings: From ASCII to Unicode and Base64.

At the lowest level, computers speak only in binary bits (0s and 1s). How does a stream of electrical currents or physical magnetism translate into the letters, punctuation, and emojis we read on screens? Let's dive deep into ASCII, Unicode, UTF-8 mapping, and the exact mathematical logic of Base64 encoding.

1. In the Beginning: The ASCII Standard

In the early days of telecommunication and computing (the 1960s), manufacturers needed a unified scheme to represent basic characters. The result was **ASCII** (American Standard Code for Information Interchange).

ASCII is a 7-bit character encoding system. Since 7 bits can represent 27 (128) combinations, it mapped numbers from 0 to 127 to specific symbols:

  • 0–31: Control characters (e.g., carriage return `\r`, line feed `\n`, tab `\t`).
  • 65–90: Uppercase English alphabet (`A` to `Z`).
  • 97–122: Lowercase English alphabet (`a` to `z`).
  • 48–57: Numbers (`0` to `9`).
  • Other numbers: Common punctuation and math symbols.

Because standard computer memory operates in 8-bit bytes, ASCII files left the eighth bit (MSB) unused or set to 0.

2. Code Page Chaos and the Birth of Unicode

As computers spread internationally, 128 characters proved completely inadequate. European, Asian, and Middle Eastern languages had their own accents, glyphs, and alphabets.

To solve this, manufacturers utilized the unused eighth bit of a byte to represent another 128 characters (extending the system to 256 characters). However, different countries used different mapping systems, known as **Code Pages**. For instance, an 8-bit character mapping value of `168` might render as the Cyrillic letter `И` in one country's layout (Code Page 1251) and as `¿` in Spanish systems (ISO-8859-1). Paste a Russian document into a Western system, and the text turned into unreadable "garbage" (referred to as *mojibake*).

To end the confusion, the industry created **Unicode**.

Unicode is not a file format or direct byte mapping; it is a universal registry of code points. The Unicode consortium assigns a unique, immutable hex identifier—written as `U+XXXX`—to every single character, letter, symbol, and emoji across history. For example:

  • The capital letter `A` is mapped to code point U+0045.
  • The Euro symbol `€` is mapped to code point U+20AC.
  • The rocket emoji `🚀` is mapped to code point U+1F680.

3. UTF-8: The Engine of the Modern Web

How do we write these abstract Unicode code points to a physical disk or transmit them over a network?

If we mapped every character using a fixed length of 32 bits (4 bytes) to ensure we could fit all 1.1 million possible Unicode symbols, standard English files would instantly quadruple in size. To solve this, developers designed **UTF-8** (Unicode Transformation Format - 8-bit).

UTF-8 is a **variable-width encoding** scheme. It represents Unicode code points using anywhere from 1 to 4 bytes:

  • 1-Byte Range (ASCII compatibility): Code points `U+0000` to `U+007F` are encoded exactly as standard ASCII bytes (0xxxxxxx). English files processed in UTF-8 are identical in size to ASCII files.
  • 2-Byte Range: Code points `U+0080` to `U+07FF` (Latin letters with diacritics, Cyrillic, Hebrew, Arabic) are encoded as two bytes (110xxxxx 10xxxxxx).
  • 3-Byte Range: Code points `U+0800` to `U+FFFF` (Chinese, Japanese, Korean, Indian scripts) are encoded as three bytes (1110xxxx 10xxxxxx 10xxxxxx).
  • 4-Byte Range: Code points `U+10000` and above (emojis, ancient scripts) require four bytes (11110xxx 10xxxxxx 10xxxxxx 10xxxxxx).

By encoding variable widths and ensuring that standard ASCII bytes remain unchanged, UTF-8 is both backwards-compatible and highly efficient. Today, it encodes over 98% of all websites.

4. What is Base64 and How Does It Work?

While UTF-8 is the ideal standard for text files, networks frequently need to transmit raw binary files (images, PDFs, zip archives) over protocols designed strictly for ASCII text (like SMTP email headers, JSON HTTP payloads, or HTML attributes).

In text-only channels, raw binary bytes are often parsed as control characters, leading to corrupted files or broken socket connections.

**Base64** solves this by converting binary data into a restricted set of 64 safe, printable ASCII characters: `A-Z`, `a-z`, `0-9`, `+`, `/`, and a padding character `=`.

The Base64 Encoding Mathematics

Since 64 is 26, we can map each of the 64 characters to a 6-bit index. The algorithm works by group-mapping:

  1. Take three 8-bit bytes (3 × 8 = 24 bits).
  2. Split those 24 bits into four 6-bit groups (4 × 6 = 24 bits).
  3. Look up each 6-bit value in the Base64 alphabet index table to produce 4 text characters.

Example: Encoding the string "Man"

CharactersM · a · n
8-bit Binary01001101 · 01100001 · 01101110
Combined bits010011010110000101101110
Split into 6-bit groups010011 · 010110 · 000101 · 101110
Decimal Indices19 · 22 · 5 · 46
Base64 OutputT · W · F · u

If the input string does not divide evenly by 3 bytes, padding characters (`=`) are added to the end of the output to align the final Base64 string to a multiple of 4 characters.

5. The Advantage of Client-Side Encoders

When you convert strings between Unicode, binary formats, hex, or Base64, processing the translation locally inside your browser is not only more secure but also highly efficient.

Modern JavaScript provides high-performance API globals like TextEncoder and TextDecoder, as well as btoa() (binary to ASCII) and atob() (ASCII to binary). Performing these conversions locally eliminates remote network latency, rate limits, and server-side risks. You can translate gigabytes of binary streams and text arrays entirely in-memory with sub-millisecond execution.