Base64 Encoding Explained: When, Why, and How to Use It

Binary-to-text conversion demystified for web developers

By Ben Praveen J · March 24, 2026

You have probably seen Base64 strings before — those long blocks of letters, numbers, and occasional +, /, and = characters. They appear in JWT tokens, email headers, data URIs, and API requests. But what is Base64 actually doing, and when should you use it? This guide explains how Base64 encoding works from the ground up, covers every common use case, and warns you about the situations where it causes more problems than it solves.

What Is Base64?

Base64 is a binary-to-text encoding scheme that converts arbitrary binary data into a string of ASCII characters. It was designed to solve a specific problem: how do you safely send binary data (images, files, raw bytes) through systems that only handle text?

Email was the original use case. SMTP (the email protocol) was designed for 7-bit ASCII text. If you tried to send an image or a PDF attachment as raw bytes, the email servers would corrupt it — some bytes would be interpreted as control characters, others would be stripped. Base64 encodes those bytes into safe, printable characters that survive any text-based transport without corruption.

The name "Base64" comes from the encoding alphabet: it uses 64 distinct characters to represent data. These are A-Z (26), a-z (26), 0-9 (10), + (1), and / (1). The = character is used for padding at the end when the input length is not a multiple of 3.

How Base64 Encoding Works Step by Step

Let us walk through encoding the string Hi! to Base64.

Step 1: Convert characters to ASCII byte values.

• H = 72, i = 105, ! = 33

Step 2: Convert each byte to 8-bit binary.

• 72 = 01001000
• 105 = 01101001
• 33 = 00100001

Step 3: Concatenate all bits into one continuous string.

010010000110100100100001 (24 bits total)

Step 4: Split into 6-bit groups.

• 010010 = 18
• 000110 = 6
• 100100 = 36
• 100001 = 33

Step 5: Map each 6-bit value to the Base64 alphabet.

• 18 = S, 6 = G, 36 = k, 33 = h

Result: Hi! encodes to SGkh

When the input length is not a multiple of 3 bytes, Base64 pads the output with = characters. For example, Hi (2 bytes) encodes to SGk=, and H (1 byte) encodes to SA==. The padding tells the decoder how many bytes were in the original input.

URL-Safe Base64

Standard Base64 uses + and / in its alphabet. These characters have special meaning in URLs: + is interpreted as a space, and / is a path separator. If you put standard Base64 in a URL, it breaks.

URL-safe Base64 (also called Base64url, defined in RFC 4648) solves this by replacing two characters:

• + becomes - (hyphen)
• / becomes _ (underscore)
• Padding = is typically omitted (since the decoder can infer the padding from the string length)

This is the encoding used in JWT tokens, which frequently appear in URLs and HTTP headers. If you are seeing - and _ in a Base64-like string, it is URL-safe Base64. Our Base64 tool supports both standard and URL-safe variants.

Common Use Cases

Data URIs in HTML and CSS

You can embed small images directly in HTML or CSS using data URIs:

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

This eliminates an HTTP request for the image — the browser decodes the Base64 string and renders the image directly. This is useful for small icons and UI elements (under 10 KB) where the overhead of an additional HTTP request outweighs the 33% size increase from Base64 encoding.

Email Attachments (MIME)

When you send an email with an attachment, the email client Base64-encodes the file and embeds it in the email body using MIME (Multipurpose Internet Mail Extensions). The receiving email client decodes it back to the original file. This is how email has handled attachments since the early 1990s.

JWT Tokens

JSON Web Tokens encode their header and payload as URL-safe Base64 strings. A JWT like eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.signature is just two Base64url-encoded JSON objects separated by dots, followed by a signature. You can decode the header and payload with any Base64 decoder to inspect the token contents.

API Authentication (Basic Auth)

HTTP Basic authentication encodes credentials as username:password in Base64. The Authorization header looks like Basic dXNlcjpwYXNz, where dXNlcjpwYXNz is the Base64 encoding of user:pass. This is encoding, not encryption — anyone who intercepts the header can decode the credentials instantly. Always use HTTPS with Basic auth.

Binary Data in JSON

JSON has no binary data type. If you need to include binary data in a JSON payload — an image thumbnail, a file attachment, a cryptographic signature — you Base64-encode it into a string. The receiving system decodes the string back to binary. This is common in REST APIs that handle file uploads via JSON request bodies.

Performance Impact: The 33% Size Overhead

Every 3 bytes of input become 4 bytes of Base64 output. That is a 33% increase in size. This overhead matters in several scenarios:

• Large images as data URIs. A 100 KB image becomes 133 KB when Base64-encoded. Worse, the Base64 string is embedded in your HTML or CSS, so it cannot be cached separately by the browser. If the same image appears on multiple pages, the browser re-downloads it with every page load instead of caching it once.
• API payloads with binary data. If your API sends large Base64-encoded files in JSON responses, the 33% overhead adds up. For files larger than a few KB, consider using multipart form data or direct binary streaming instead.
• Database storage. Storing Base64 strings in a database uses 33% more space than storing raw binary in a BLOB column. Use binary column types when your database supports them.

When NOT to use Base64:

• Images larger than 10 KB — serve them as separate files for caching
• Large file transfers — use multipart uploads or binary streaming
• Database storage of binary data — use BLOB columns
• Anything that already has a binary-safe transport (WebSockets in binary mode, gRPC, etc.)

Base64 in Different Programming Languages

JavaScript (Browser and Node.js)

In browsers, use btoa() to encode and atob() to decode. These functions handle ASCII strings only. For Unicode strings, first encode to UTF-8 bytes:

btoa('Hello') returns SGVsbG8=

atob('SGVsbG8=') returns Hello

In Node.js, use Buffer.from(string).toString('base64') to encode and Buffer.from(base64, 'base64').toString() to decode. The Buffer API handles all character encodings natively.

Python

The base64 module provides encoding and decoding:

import base64

base64.b64encode(b'Hello') returns b'SGVsbG8='

base64.urlsafe_b64encode(b'Hello') for URL-safe variant

Command Line

On macOS and Linux: echo -n 'Hello' | base64 to encode, echo 'SGVsbG8=' | base64 --decode to decode. On Windows PowerShell: [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello')).

Or skip the command line entirely and use our online Base64 encoder/decoder — paste text or upload a file and get instant results.

Security: Base64 Is NOT Encryption

This is the most common misconception about Base64, and it is a dangerous one. Base64 is a reversible encoding — anyone can decode it without a key, password, or secret. It provides zero confidentiality.

We regularly see developers Base64-encoding passwords, API keys, or personal data and assuming it is "protected." It is not. A Base64-encoded string like cGFzc3dvcmQxMjM= can be decoded by anyone in seconds — it is just password123.

If you need to protect data:

• For data at rest: Use AES-256 encryption, then optionally Base64-encode the ciphertext for safe storage in text fields.
• For data in transit: Use HTTPS/TLS. The transport layer encrypts everything, including Base64-encoded content.
• For passwords: Never encode or encrypt passwords — hash them with bcrypt, scrypt, or Argon2. Use a hash generator to understand the difference between encoding and hashing.
• For tokens and secrets: Store them in environment variables or a secrets manager, not in Base64-encoded config files.

For URL encoding needs where you want to safely encode special characters in URLs (a different problem from Base64), see our URL Encoder tool.

FAQ

Is Base64 encoding the same as encryption?

No. Base64 is a reversible encoding scheme, not encryption. Anyone can decode Base64 without a key or password. It provides zero security. If you need to protect data, use actual encryption (AES, RSA) and then optionally Base64-encode the encrypted output for safe transport.

Why does Base64 increase file size by 33%?

Base64 represents every 3 bytes of binary data using 4 ASCII characters. Each character uses one byte, so 3 bytes become 4 bytes — a 33% increase. This overhead is the trade-off for being able to safely embed binary data in text-based formats.

What is the difference between standard Base64 and URL-safe Base64?

Standard Base64 uses + and / characters, which have special meaning in URLs. URL-safe Base64 replaces + with - and / with _, and typically omits the = padding. This makes it safe to use in URLs, query parameters, and filenames without additional encoding.

Should I Base64-encode images in my HTML?

Only for very small images (under 10 KB), like icons or tiny UI elements. For larger images, Base64 encoding increases the size by 33%, prevents browser caching, and bloats your HTML. Serve larger images as separate files so the browser can cache them independently.

Can I Base64-encode any file type?

Yes. Base64 works on any binary data — images, PDFs, audio, video, executables, or any other file type. It converts the raw bytes to text characters regardless of the original format. However, the 33% size increase makes it impractical for large files.

← Blog index  |  Base64 Encoder  |  URL Encoder  |  Hash Generator  |  All tools