If you are a developer, you have inevitably encountered Base64 encoding. It is absolutely everywhere across the modern web. You see it in data URLs for inline images, nested inside of HTTP headers for basic authentication, and forming the very foundation of modern session tokens.
However, many developers treat Base64 as a magical black box. They invoke a built-in language function, pass a string, and trust the output. But under the hood, Base64 is an elegant, purely mathematical process of translating binary data.
Need to encode or decode a string right now without reading the theory? Jump straight to our free, local-first Base64 Encoder and Decoder tool to get your results instantly.
If you are ready to understand the underlying mechanics of binary-to-text translation, let's pull back the curtain and look at how Base64 encoding actually works.
Why Do We Need Base64 Encoding?
To understand how Base64 works, we first must understand the problem it originally set out to solve: transmitting raw binary data across legacy, text-based protocols.
In the early days of computing, network protocols like SMTP (Simple Mail Transfer Protocol) and early HTTP implementations were designed explicitly to handle 7-bit US-ASCII characters. These systems expected standard printable text—letters, numbers, and basic punctuation.
Binary files—such as images, compiled Executables, or compressed archives—use the full 8-bit spectrum of a byte (values ranging from 0 to 255). If you attempt to send raw binary data through a text-based protocol, the receiving system will misinterpret certain byte values as hidden control characters. For example, a random byte in your JPEG image might accidentally trigger an "End of Transmission" command, instantly dropping the connection and corrupting the file transfer.
Base64 provides an elegant solution. It takes raw, unpredictable 8-bit binary data and safely translates it into a restricted alphabet of known, printable characters that any system, old or new, can safely transmit without data corruption.
base64 valid characters
When we encode data into Base64, we are converting it into a carefully curated alphabet. The standard specifies exactly 64 distinct characters that are universally safe across all computer systems.
If you are ever verifying a payload, here are the base64 valid characters:
- Uppercase Letters:
AthroughZ(26 characters) - Lowercase Letters:
athroughz(26 characters) - Numbers:
0through9(10 characters) - Symbols:
+(Plus) and/(Forward Slash) (2 characters)
(Note: There is a separate URL-safe variant of Base64 that replaces the + and / characters with hyphens - and underscores _ to prevent routing conflicts in web links).
Because there are exactly 64 characters in this alphabet, every single valid Base64 character represents exactly 6 bits of underlying binary data ($2^6 = 64$). This 6-bit mapping is the entire secret to how the math works.
The Step-by-Step Math: Encoding "Cat"
Let's execute the encoding process manually. The core concept of Base64 is turning groups of three 8-bit bytes into four 6-bit characters.
We will encode the 3-letter word: "Cat".
Step 1: ASCII Translation
First, the computer translates the text characters into their corresponding decimal ASCII values.
- C = 67
- a = 97
- t = 116
Step 2: Convert to 8-bit Binary
Next, those decimal numbers are converted into raw 8-bit binary sequences.
- 67 =
01000011 - 97 =
01100001 - 116 =
01110100
Step 3: Combine into a 24-bit Block
We take those three 8-bit bytes and smash them together into a single, continuous 24-bit stream of data.
010000110110000101110100
Step 4: Split into 6-bit Chunks
Now, instead of reading the binary stream in chunks of 8 bits, we divide the 24-bit block into four chunks of 6 bits each. (Remember: $3 \times 8 = 24$, and $4 \times 6 = 24$. The total number of bits remains completely unchanged).
- Chunk 1:
010000 - Chunk 2:
110110 - Chunk 3:
000101 - Chunk 4:
110100
Step 5: Convert Chunks to Decimal
Now we convert those new 6-bit binary chunks back into standard decimal numbers.
010000= 16110110= 54000101= 5110100= 52
Step 6: Map to the Base64 Alphabet
Finally, we take these decimal values and look them up in the official Base64 index table (where A=0, B=1, etc.).
- 16 = Q
- 54 = 2
- 5 = F
- 52 = 0
The final output? The string "Cat" becomes the Base64 encoded string "Q2F0".
Through pure mathematical translation, we turned three bytes of input into four bytes of completely text-safe output.
The "=" Signs: Explaining Padding
If you work with Base64 frequently, you have probably noticed that strings often end with one or two equals signs, like == or =.
In our "Cat" example, everything worked perfectly because our input was exactly three characters long. Our 3 bytes translated perfectly into a 24-bit block, yielding four 6-bit characters. But what happens if you try to encode a word that is only 1 or 2 letters long?
If you try to encode the word "Ca" (2 bytes / 16 bits), you cannot form a complete 24-bit block. Base64 algorithms solve this by adding padding.
The encoder will append temporary zero-bits to the end of the binary stream until it forms a complete 6-bit chunk. Then, to signify to the receiving system that these extra bits are artificially added padding and not real data, the algorithm appends the = character to the final string block.
- If your input falls 1 byte short of a multiple of three, the output gets one padding character:
= - If your input falls 2 bytes short of a multiple of three, the output gets two padding characters:
==
Because of this mechanism, you will only ever see zero, one, or two equals signs at the end of a payload. You will never see three.
Base64 is NOT Encryption
One of the most dangerous and persistent misconceptions in software engineering is that Base64 provides data security.
Base64 is an encoding scheme, not an encryption algorithm.
Encoding simply translates data from one highly documented format to another. There are no cryptographic keys, no mathematical hashing, and no secrets. Anyone who intercepts a Base64 string can decode it instantly.
Unfortunately, because Base64 text looks confusing and unreadable to a human (e.g., eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZ...), junior developers sometimes mistakenly use it to "secure" passwords or sensitive session objects. Furthermore, some legacy enterprise applications historically used Base64 as a quick obfuscation method, setting a bad precedent.
This is especially critical when dealing with modern authentication mechanisms like JSON Web Tokens (JWTs). The payload of a standard JWT is purely Base64 encoded—it is explicitly not encrypted. If you put sensitive user data inside a JWT, anyone who captures that token can easily read everything inside. You can test this yourself using our dedicated JWT Decoder tool to instantly inspect the contents of any token payload.
Always remember: Encoding protects data structure from network corruption; Encryption protects data contents from malicious actors. Never confuse the two.
Frequently Asked Questions
How does base64 encoding work?
It works by taking standard 8-bit binary data (bytes) and mathematically re-grouping it into smaller 6-bit chunks. Each of these 6-bit chunks is then represented by one of 64 predetermined safe text characters, ensuring the data can pass through text-only network protocols without structural corruption.
Is base64 encrypted?
No. Base64 offers zero cryptographic security. It is simply a public translation map between data formats. Any system or individual with access to a Base64 string can instantly decode it back into its original text or binary format without requiring any passwords, keys, or special permissions.
What are base64 valid characters?
The strict alphabet defined by the RFC includes 64 characters: all capital letters (A-Z), all lowercase letters (a-z), numbers (0-9), the plus sign (+), and the forward slash (/). The equals sign (=) is also permitted strictly at the very end of the string to indicate mathematical padding.