Base64 encoding explained: encode, decode and common uses (2026)

The most common Base64 mistake is treating it like encryption.

A developer sees a long string of letters, numbers, and equals signs. It looks scrambled. It looks like something was done to it to make it unreadable. They assume it is protected. They are wrong.

Base64 makes data portable, not secure. Anyone who can decode Base64 can read its contents -- and decoding it takes one function call in any programming language. Encoding changes representation, not confidentiality. The data is just as readable as it was before encoding; it is simply expressed in a different character set that works across text-based systems.

Understanding what Base64 actually does, and what it does not do, prevents a specific category of security mistake that shows up in bug bounty reports more often than it should.

Base64 quick reference

Base64 quick answer

Direct answer: Base64 is a binary-to-text encoding scheme that converts binary data (images, files, binary strings) into ASCII characters that can be safely transmitted over text-only systems. It is reversible without any key.

What is Base64?

Direct answer: Base64 is a binary-to-text encoding method that converts any binary data into a sequence of 64 printable ASCII characters. It is defined in RFC 4648 and is widely used to transmit binary content through systems that only support text.

The name comes from the character set: Base64 uses 64 distinct characters (A-Z, a-z, 0-9, +, /) to represent any binary data. Every three bytes of input becomes four Base64 characters of output.

Why was Base64 created?

Direct answer: Base64 was created to solve a specific compatibility problem: early email systems and text-based protocols could only transmit ASCII text, which meant binary attachments (images, documents, programs) could not be sent directly.

In the early days of the internet, many systems treated text and binary data as fundamentally incompatible. Email systems built on SMTP, for example, were designed for plain text. When someone wanted to attach an image to an email, there was no mechanism to include raw binary data in a text-only message without corrupting it.

Certain bytes in binary data have values that text-based systems interpreted as control characters rather than data. A byte with the value 13 is a carriage return. A byte with the value 10 is a newline. A byte with the value 0 is a null terminator. Binary files routinely contain these byte values in meaningful positions. When an email system encountered them, it treated them as formatting commands and garbled the binary content.

Base64 solved this by converting all binary data into a subset of printable ASCII characters that have no special meaning in text-based protocols. The result is longer than the original, but it transmits cleanly through any system that handles text.

This problem is less acute today -- modern protocols like HTTP/2 and HTTP/3 are binary-safe. But Base64 persists because it is now deeply embedded in web standards, email formats, JWT tokens, and API design patterns. The format is now so universal that using it remains conventional even in contexts where it is not strictly necessary.

How Base64 encoding works

Direct answer: Base64 takes binary data in groups of 3 bytes (24 bits), splits each group into four 6-bit chunks, maps each 6-bit chunk to one of 64 characters, and outputs those characters. Three bytes in always becomes four characters out.

Base64 character set explained

Direct answer: Base64 uses 64 printable ASCII characters plus one padding character. The character set was chosen to avoid characters that text-based systems might interpret as control sequences.

Total: 64 data characters + 1 padding character. These characters are present in every ASCII-compatible encoding and are safe to transmit through any text-based system.

Real example 1: encode “Hello World”

Input text: Hello World

Decode back: SGVsbG8gV29ybGQ= → Hello World

Every Base64 tool -- in your browser console, Python, Node.js, Go, anywhere -- produces this identical result. The encoding is deterministic and standard.

In code:

// Browser JavaScript
btoa('Hello World')  // "SGVsbG8gV29ybGQ="

// Node.js
Buffer.from('Hello World').toString('base64')
// "SGVsbG8gV29ybGQ="

Browser: btoa() and atob() (MDN Web Docs). Node.js: Buffer API docs.

Real example 2: Base64 in APIs

Direct answer: APIs use Base64 to transmit binary data (images, files, PDFs) through JSON, to encode authentication credentials in HTTP headers, and to represent binary fields in text-based response formats.

HTTP Basic Authentication

The most common API use of Base64 is HTTP Basic Auth (RFC 7617). The authorization header value is username:password encoded as Base64:

# Credentials: user@example.com:mypassword123
# base64("user@example.com:mypassword123")
# => dXNlckBleGFtcGxlLmNvbTpteXBhc3N3b3JkMTIz

Authorization: Basic dXNlckBleGFtcGxlLmNvbTpteXBhc3N3b3JkMTIz

# Decode instantly -- no key needed:
# atob("dXNlckBleGFtcGxlLmNvbTpteXBhc3N3b3JkMTIz")
# => "user@example.com:mypassword123"

Image uploads in JSON APIs

When an API needs to accept an image in a JSON request body, Base64 is the standard approach:

{
  "filename": "profile.jpg",
  "content_type": "image/jpeg",
  "data": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAA..."
}

The data:image/jpeg;base64, prefix is a data URL -- a convention for embedding binary data directly in a text field. The browser and many APIs understand this format natively.

Real example 3: Base64 in JWT tokens

Direct answer: JWT tokens use Base64url encoding (a URL-safe variant of Base64) for the header and payload sections. The signature is also Base64url-encoded but is cryptographically generated, not just encoded data.

A JWT looks like three Base64url-encoded strings separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTc1MDAwMDAwMH0
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

# Header (Base64url decode):
# {"alg":"HS256","typ":"JWT"}

# Payload (Base64url decode):
# {"sub":"user_123","exp":1750000000}

# Signature: cryptographic hash -- readable but not forgeable
# without the secret key.

Base64 vs encryption

Direct answer: Base64 and encryption are fundamentally different tools. Base64 changes how data looks. Encryption makes data unreadable without the correct key. Using Base64 where encryption is needed is a security vulnerability.

Base64 vs hashing

Direct answer: Base64 encodes data reversibly. Hashing is a one-way operation that produces a fixed-size fingerprint. They serve completely different purposes and should not be confused or substituted for each other.

Common uses of Base64

Common Base64 mistakes

Is Base64 secure?

Direct answer: No. Base64 provides zero security. It is an encoding, not encryption. Anyone with the encoded data can decode it instantly with no key.

What Base64 protects against: nothing. What Base64 is designed for: transmitting binary data through text-only systems safely and universally.

The specific scenarios where this misconception causes real damage:

Proper security alternatives: TLS for data in transit, AES-256 or similar for data at rest, bcrypt/argon2 for passwords, key management services (AWS KMS, HashiCorp Vault) for secret storage.

Base64 encoder/decoder example

Every programming language has Base64 in its standard library. Here are the most commonly used implementations:

// Browser JavaScript
btoa('Hello World')           // "SGVsbG8gV29ybGQ="
atob('SGVsbG8gV29ybGQ=')     // "Hello World"

// Node.js
Buffer.from('Hello World').toString('base64')
// "SGVsbG8gV29ybGQ="
Buffer.from('SGVsbG8gV29ybGQ=', 'base64').toString('utf8')
// "Hello World"

import base64

base64.b64encode(b'Hello World')
# b'SGVsbG8gV29ybGQ='

base64.b64decode('SGVsbG8gV29ybGQ=')
# b'Hello World'

# Base64url (for JWTs)
base64.urlsafe_b64decode('SGVsbG8gV29ybGQ=')

echo -n "Hello World" | base64      # Encode
# SGVsbG8gV29ybGQ=

echo "SGVsbG8gV29ybGQ=" | base64 -d  # Decode
# Hello World

package main

import (
    "encoding/base64"
    "fmt"
)

func main() {
    encoded := base64.StdEncoding.EncodeToString([]byte("Hello World"))
    fmt.Println(encoded) // SGVsbG8gV29ybGQ=

    decoded, _ := base64.StdEncoding.DecodeString("SGVsbG8gV29ybGQ=")
    fmt.Println(string(decoded)) // Hello World

    // Base64url (for JWTs)
    urlEncoded := base64.URLEncoding.EncodeToString([]byte("Hello World"))
    fmt.Println(urlEncoded) // SGVsbG8gV29ybGQ=
}

# Base64url strings often omit padding
s = 'SGVsbG8gV29ybGQ'          # missing trailing =
s += '=' * (-len(s) % 4)        # adds correct padding
base64.b64decode(s)              # now decodes correctly

For debugging outside of code -- inspecting a JWT payload, verifying an API response, checking what a config value decodes to -- use the Vortenza Base64 Encoder/Decoder. Paste the Base64 string, decode it, and see immediately what the value contains. The reverse (encode arbitrary text) is useful for constructing test request headers or preparing data for API calls.

Base64 performance considerations

Direct answer: Base64 encoding adds approximately 33% to the size of any encoded data. This matters for large files, high-frequency API calls, and storage at scale.

Three bytes of input become four characters of output. Four characters in standard ASCII are 4 bytes. So 3 bytes in becomes 4 bytes out -- an overhead of 33.33% (4/3 - 1). 1 KB of binary data becomes approximately 1.33 KB when Base64-encoded.

Base64 best practices

One-minute Base64 audit

Quick Base64 answers

15 answered questions, from basic to advanced.

Frequently asked questions

Final verdict

Tools used in this guide

Related guides