Base64 Encoding Explained

The Transmission of Binary Data

In early telecommunications and network design, systems were built to transmit standard, printable text characters. As networks grew, developers needed to transmit binary data—such as images, compressed zip files, or compiled executables—over these text-only protocols.

Directly transmitting raw binary data created significant challenges:

• Character Corruption: Mail servers, proxies, and gateways often stripped control characters or modified line endings (like converting \n to \r\n), corrupting the file payload.
• Protocol Limitations: Many database fields, JSON formats, and XML protocols only accept valid ASCII characters.
• Encoding Errors: Non-printable bytes (values 0-31 and 127) can be interpreted as control characters by terminal emulators, causing data loss or unexpected behavior.

To resolve these issues, developers created binary-to-text encoding schemes. The most common standard is Base64.

In this article, we will examine the mechanics of Base64 encoding, look at calculation examples, explain padding logic, compare it with other encoding schemes, and outline its modern use cases.

---

What is Base64 Encoding?

Base64 is an encoding scheme that represents binary data using a set of 64 printable characters. This alphabet is defined by RFC 4648 and includes:

• 26 uppercase letters: A through Z
• 26 lowercase letters: a through z
• 10 digits: 0 through 9
• 2 symbols: + (plus) and / (slash)

Because the alphabet contains exactly 64 characters, each character represents exactly 6 bits of information ($2^6 = 64$).

In comparison, a standard byte consists of 8 bits of information ($2^8 = 256$ possibilities). Base64 works by grouping bytes together and dividing their bits into blocks of 6 bits. You can convert strings locally using our client-side Base64 Converter.

---

The Step-by-Step Encoding Process

To understand how Base64 converts data, let’s trace the conversion of three ASCII characters: Cat.

Step 1: Convert to Binary Bytes

First, convert each character to its 8-bit binary representation:

• C $\rightarrow$ ASCII value $67$ $\rightarrow$ Binary 01000011
• a $\rightarrow$ ASCII value $97$ $\rightarrow$ Binary 01100001
• t $\rightarrow$ ASCII value $116$ $\rightarrow$ Binary 01110100

Concatenating these bytes yields a 24-bit block: 010000110110000101110100

Step 2: Split into 6-Bit Blocks

Next, divide this 24-bit block into four 6-bit chunks:

1. 010000 (value $16$)
2. 110110 (value $54$)
3. 000101 (value $5$)
4. 110100 (value $52$)

Step 3: Map to the Base64 Alphabet

Finally, map each 6-bit value to the corresponding character in the Base64 index table:

• $16$ $\rightarrow$ Q
• $54$ $\rightarrow$ 2
• $5$ $\rightarrow$ F
• $52$ $\rightarrow$ 0

The text Cat encodes to QzF0. This process increases the data size by approximately 33% (3 bytes of input become 4 bytes of output).

---

Understanding Padding Indicator Logic

What happens if the input data length is not a multiple of three bytes? This is where padding comes in, using the = symbol.

Consider the word Ca (2 bytes of input, or 16 bits):

1. Binary representation: 01000011 (C) and 01100001 (a) $\rightarrow$ 0100001101100001 (16 bits).
2. 6-bit division:
   • Chunk 1: 010000 (value $16$ $\rightarrow$ Q)
   • Chunk 2: 110110 (value $54$ $\rightarrow$ 2)
   • Chunk 3: 0001 (only 4 bits left). We pad this with two zeros to make it 6 bits: 000100 (value $4$ $\rightarrow$ E)
   • Chunk 4: Missing completely.
3. Padding Output: We add one = symbol on the end to show that 1 byte was missing from the final 24-bit block.

The output for Ca is QzE=.

If the input is only 1 byte (e.g. C), we pad the end with two = symbols, resulting in Qw==.

Padding Summary Table

Input Bytes	Bits Available	6-Bit Chunks	Padding Characters	Output
3 bytes	24 bits	4 complete chunks	None	AAAA
2 bytes	16 bits	3 chunks + partial	1 =	AAA=
1 byte	8 bits	1 chunk + partial	2 =	AA==

---

Critical Warning: Encoding Is Not Encryption

A common cybersecurity mistake is using Base64 to secure data.

Base64 encoding is not encryption. It does not use keys, and it is not designed to hide information. It is a standardized translation scheme. Anyone who intercepts a Base64 string can decode it instantly without a password.

If you use Base64 to store passwords or API keys in configuration files, you are essentially storing them in plaintext. For actual security, you must encrypt your data or generate random credentials using our Password Generator.

Why This Matters

According to the 2025 Verizon Data Breach Investigations Report, 49% of breaches involved the use of stolen credentials. Storing passwords as Base64 (or any encoding) in your database provides zero protection against this attack vector. Always hash passwords with bcrypt, scrypt, or Argon2, and store API keys in encrypted vaults.

---

Base64 vs. Other Binary-to-Text Encodings

Base64 is not the only binary-to-text encoding scheme. Here is how it compares to alternatives:

Encoding	Bits Per Character	Alphabet Size	Output Size (vs. Input)	Primary Use Case
Base64	6	64	+33%	General-purpose binary encoding
Base32	5	32	+60%	Case-insensitive systems, TOTP seeds
Base16 (Hex)	4	16	+100%	Hash display, memory dumps
Base85	5	85	+25%	PostScript, PDF compression
Base256	8	256	+0%	Raw binary (no encoding)

When to Choose Base64 Over Alternatives

• Choose Base64 when you need a balance of compactness and compatibility. It works universally across email (MIME), URLs, JSON, XML, and HTML.
• Choose Base32 when case sensitivity is a concern. TOTP (Time-Based One-Time Password) secrets are encoded in Base32 because authenticator apps need case-insensitive input. Our Password Generator can generate secure TOTP-compatible secrets.
• Choose Hex (Base16) when displaying cryptographic hashes like SHA-256. Every SHA-256 Hash Generator outputs hexadecimal strings because the 16-character alphabet (0-9, a-f) is universally recognized.
• Choose Base85 when minimizing size matters most. Base85 encodes every 4 bytes of input into 5 ASCII characters, achieving 80% efficiency compared to Base64’s 75%.

---

Standard vs. URL-Safe Base64

The standard Base64 alphabet contains the symbols + and /. In web environments, these symbols can cause issues:

• + is often interpreted as a space in query parameters.
• / is interpreted as a folder separator in URL path routing.

To prevent parsing errors, developers use URL-Safe Base64. This variant replaces:

• + with - (hyphen)
• / with _ (underscore)

Additionally, the padding symbol = is often stripped from the end of URL-Safe Base64 strings to keep links clean. You can escape URL parameters safely using our local URL Encoder/Decoder.

When to Use URL-Safe Base64

• JWTs (JSON Web Tokens): The header and payload segments of a JWT use URL-safe Base64 without padding. A typical JWT looks like: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U
• Firebase Push IDs: Firebase generates 20-character URL-safe Base64 identifiers for database records.
• CSRF Tokens: Many web frameworks encode random tokens using URL-safe Base64 for use in form fields and URL parameters.

---

Modern Use Cases for Base64

Base64 is widely used in modern web applications:

1. Data URIs

Embedding small images directly inside HTML or CSS files reduces the number of HTTP requests needed to load a page. For example:

<img src="data:image/png;base64,iVBORw0KGgo..." alt="Logo" />

Data URIs are ideal for small assets like icons, logos, and decorative elements. However, they increase HTML file size by approximately 33%, so they should not be used for large images. Studies show that embedding assets as Base64 can improve page load performance by 15-20% for small images by eliminating additional HTTP round trips.

2. API File Transfers

Sending binary attachments (such as PDF invoices or profile photos) inside JSON API payloads is common in RESTful APIs. JSON cannot represent raw binary data, so Base64 encoding provides a standard way to embed files:

{
  "filename": "invoice.pdf",
  "content_type": "application/pdf",
  "data": "JVBERi0xLjQKJeLj..."
}

3. Basic Authentication

HTTP Basic Authentication encodes username and password credentials (separated by a colon) inside HTTP headers:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Important: Base64 encoding does not protect these credentials. Basic Authentication must always be used over HTTPS to prevent interception. According to OWASP, Basic Authentication without TLS is one of the top 10 most critical web application security risks.

4. System UUIDs

Converting 128-bit UUIDs into compact, 22-character Base64 strings to save URL space. You can generate raw UUIDs using our secure UUID Generator.

5. Email Attachments (MIME)

The MIME (Multipurpose Internet Mail Extensions) standard uses Base64 to encode binary email attachments. Without this encoding, email servers would corrupt image files, PDFs, and other binary content during transmission.

6. Cryptographic Key Serialization

SSH keys, TLS certificates, and JWT signatures all use Base64 (or Base64url) to represent binary cryptographic material as printable strings. For example, an RSA public key in SSH format is a Base64-encoded blob between ssh-rsa and the key comment.

---

How to Decode Base64

Decoding Base64 is the reverse process of encoding. Each Base64 character maps back to its 6-bit value, which is then concatenated and split into 8-bit bytes:

Example: Decoding QzF0 Back to Cat

Base64 Char	Index Value	6-Bit Binary
Q	16	010000
2	54	110110
F	5	000101
0	52	110100

Concatenated binary: 010000110110000101110100

Split into 8-bit bytes:

• 01000011 = 67 = C
• 01100001 = 97 = a
• 01110100 = 116 = t

Decoding in Practice

You can decode Base64 in any programming language:

• JavaScript: atob("QzF0") returns "Cat"
• Python: import base64; base64.b64decode("QzF0") returns b"Cat"
• Command Line: echo "QzF0" | base64 --decode

Or use our browser-based Base64 Converter for quick conversions without writing code.

---

Performance and Storage Considerations

Base64’s 33% size overhead has measurable impacts on storage and bandwidth:

Original Size	Base64 Size	Overhead	Impact
1 KB	1.33 KB	333 bytes	Negligible
1 MB	1.33 MB	333 KB	Noticeable on mobile
100 MB	133 MB	33 MB	Significant bandwidth cost

For large files, consider whether Base64 encoding is necessary. Streaming protocols, binary WebSocket frames, and file upload APIs often accept raw binary data, eliminating the need for Base64 altogether.

When to Avoid Base64

• Large file transfers: Use chunked binary uploads instead of embedding entire files in JSON.
• Database storage: Store binary data as BLOB or BYTEA columns rather than Base64 text.
• Compression: Always compress data before Base64 encoding to minimize the size penalty.

---

Security Implications

While Base64 is not a security tool, it does appear in security contexts that developers should understand:

API Keys and Secrets

Many cloud providers (AWS, GCP, Azure) represent API keys and tokens as Base64-encoded strings. This does not mean the keys are encrypted—they are simply formatted for easy transport. Always treat Base64-encoded secrets as plaintext.

JWT Tokens

JSON Web Tokens use Base64url encoding for their header and payload segments. The signature segment is a cryptographic signature (using HMAC-SHA256 or RSA) that verifies the token has not been tampered with. You can generate strong secrets for JWT signing using our Password Generator.

Git LFS

Git Large File Storage (LFS) uses Base64-encoded pointers to track large files without bloating the repository. The pointer files contain Base64-encoded SHA-256 hashes of the actual file contents.

---

Frequently Asked Questions

Is Base64 encoding the same as encryption?

No. Base64 is an encoding scheme, not encryption. It does not use keys and provides no confidentiality. Anyone can decode Base64 without any credentials. For actual encryption, use algorithms like AES-256 or RSA.

Can Base64-encoded data be decoded without the original file?

Yes. Base64 is a reversible encoding. You can decode any Base64 string back to its original binary representation without any additional information.

Does Base64 increase file size?

Yes, Base64 encoding increases data size by approximately 33%. Three bytes of binary input become four bytes of Base64 output. This is the inherent trade-off for representing binary data as ASCII text.

What is URL-safe Base64?

URL-safe Base64 replaces the `+` character with `-` and `/` with `_` to prevent issues in URLs and file paths. It is commonly used in JWTs, Firebase push IDs, and web application tokens.

When should I use Base32 instead of Base64?

Use Base32 when you need case-insensitive encoding (like TOTP seeds for authenticator apps) or when the encoded data must pass through systems that are case-sensitive. Base32 is less compact than Base64 but more portable across different systems.

How do I know if a string is Base64-encoded?

A valid Base64 string contains only characters from the Base64 alphabet (`A-Z`, `a-z`, `0-9`, `+`, `/`), with optional `=` padding at the end. If you see a string matching this pattern, it is likely Base64-encoded. You can verify by decoding it with our [Base64 Converter](/base64-converter).