UtilopiaUtilopia

Command Palette

Search for a command to run...

Base64 Encoding Explained for Developers

Base64 Encoding Explained for Developers

March 4, 2026·7 min readdeveloperbase64encodingweb-development

You've seen Base64 strings everywhere — in email attachments, data URIs, API authentication headers, JWTs. They look like random gibberish: SGVsbG8gV29ybGQ=. But Base64 isn't encryption, isn't compression, and isn't random. It's a simple encoding scheme that converts binary data into a limited set of ASCII characters so it can travel safely through systems designed for text.

What Base64 Actually Does

Base64 takes any binary data — a JPEG image, a PDF, a string of text, a cryptographic key — and represents it using only 64 characters: A-Z, a-z, 0-9, +, and /, with = for padding.

Why? Because many systems (email, JSON, URLs, HTTP headers) can only reliably handle ASCII text. If you try to embed raw binary data in an email, certain byte values (like null bytes or control characters) will be misinterpreted, truncated, or corrupted by mail servers along the way. Base64 solves this by translating every possible byte into characters that survive any text-based transport.

The tradeoff is size: Base64 encoding increases data size by approximately 33%. Every 3 bytes of input become 4 characters of output.

How the Encoding Works

Base64 processes input in groups of 3 bytes (24 bits). It splits those 24 bits into four groups of 6 bits each, then maps each 6-bit value to a character using this table:

Value Char Value Char Value Char Value Char
0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
2 C 18 S 34 i 50 y
3 D 19 T 35 j 51 z
4 E 20 U 36 k 52 0
5 F 21 V 37 l 53 1
6 G 22 W 38 m 54 2
7 H 23 X 39 n 55 3
8 I 24 Y 40 o 56 4
9 J 25 Z 41 p 57 5
10 K 26 a 42 q 58 6
11 L 27 b 43 r 59 7
12 M 28 c 44 s 60 8
13 N 29 d 45 t 61 9
14 O 30 e 46 u 62 +
15 P 31 f 47 v 63 /

Step-by-Step Example: Encoding "Hi"

Let's encode the string Hi:

Step 1: Get the ASCII values. - H = 72, i = 105

Step 2: Convert to binary (8 bits each). - H = 01001000, i = 01101001 - Combined: 01001000 01101001

Step 3: Since we have 2 bytes (not divisible by 3), pad with zeros to make 18 bits, then split into three 6-bit groups. - 010010 000110 100100

Step 4: Map each 6-bit value to the Base64 character. - 010010 = 18 → S - 000110 = 6 → G - 100100 = 36 → k

Step 5: Since the input was 2 bytes (one byte short of a 3-byte group), add one = padding character.

Result: HiSGk=

Try it yourself with a Base64 Encoder/Decoder — paste any text and see the encoded output instantly.

The Padding Rule

Base64 processes 3 bytes at a time. When the input length isn't divisible by 3: - 1 byte remaining: 2 Base64 characters + == - 2 bytes remaining: 3 Base64 characters + = - Exactly divisible by 3: No padding needed

The = characters tell the decoder how many padding bytes were added, so it can strip them when decoding.

When to Use Base64

Embedding Images in HTML/CSS (Data URIs)

Instead of referencing an external file, you can embed an image directly in HTML:

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

This eliminates an HTTP request but increases the HTML size by 33%. Use it for small images (icons, logos under ~5KB). For larger images, a separate file with proper caching is more efficient.

Email Attachments (MIME)

Email was designed for 7-bit ASCII text. When you attach a PDF or image, your email client encodes the binary file as Base64 and embeds it in the message body with a MIME header:

Content-Transfer-Encoding: base64
Content-Type: application/pdf; name="report.pdf"

JVBERi0xLjQKMSAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZwov...

The recipient's client decodes it back to the original file. This is why email attachments increase message size — the 33% Base64 overhead plus MIME headers.

HTTP Basic Authentication

The Authorization header encodes credentials in Base64:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Decode dXNlcm5hbWU6cGFzc3dvcmQ= and you get username:password. This is not security — it's just encoding. Without HTTPS, anyone watching the traffic can decode it trivially. Base64 here exists only to handle special characters safely in an HTTP header.

JSON Web Tokens (JWT)

JWTs consist of three Base64URL-encoded segments separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

Each segment (header, payload, signature) is a JSON object encoded in Base64URL — a variant that replaces + with - and / with _ to make the result URL-safe. You can decode JWT tokens with a JWT Decoder to inspect their contents.

Storing Binary in JSON or XML

JSON has no binary type. If you need to include binary data (an encryption key, a file hash, an image thumbnail), Base64 encoding it into a string is the standard approach:

{
  "avatar": "data:image/jpeg;base64,/9j/4AAQSkZJRg...",
  "encryption_key": "c2VjcmV0LWtleS0xMjM0NTY3ODkw"
}

When NOT to Use Base64

For security or encryption. Base64 is trivially reversible. Anyone can decode a Base64 string — there's no key, no secret, no protection. If you need to protect data, use actual encryption (AES, RSA).

For large files. The 33% size overhead matters when you're dealing with megabytes. A 10MB image becomes ~13.3MB in Base64. Use proper binary transport (multipart upload, binary protocol) instead.

For URLs with sensitive data. While Base64URL encoding makes data URL-safe, putting sensitive information in URLs (even encoded) creates security risks — URLs appear in browser history, server logs, and referrer headers.

For compression. Base64 doesn't compress data. It makes data larger. If you need to reduce size, compress first (gzip, brotli), then Base64 encode the compressed output if you need text representation.

Base64 Variants

Not all Base64 is the same. Different contexts use slightly different character sets:

Variant Characters 62-63 Padding Used In
Standard (RFC 4648) + / = Email, PEM certificates
URL-safe (RFC 4648 §5) - _ Optional JWTs, URLs, filenames
MIME (RFC 2045) + / = Email attachments (with line breaks)
XML + / = XML documents

The URL-safe variant exists because +, /, and = have special meanings in URLs. Standard Base64 in a URL would break parsing. Most modern APIs and libraries use URL-safe Base64 by default.

Base64 in Different Languages

Every programming language has built-in Base64 support:

JavaScript (Browser):

btoa("Hello World")      // "SGVsbG8gV29ybGQ="
atob("SGVsbG8gV29ybGQ=") // "Hello World"

JavaScript (Node.js):

Buffer.from("Hello World").toString("base64")
Buffer.from("SGVsbG8gV29ybGQ=", "base64").toString()

Python:

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

Command line:

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

Or skip the code entirely and use a Base64 Encoder/Decoder for quick one-off conversions.

Frequently Asked Questions

Is Base64 encoding the same as encryption?

No. Base64 is encoding, not encryption. It transforms data into a different representation but provides zero security. Anyone can decode a Base64 string instantly without any key or secret. If you need to protect data, use actual encryption algorithms like AES or RSA. Base64 is for transport compatibility, not confidentiality.

Why does Base64 increase file size by 33%?

Base64 converts every 3 bytes of input into 4 ASCII characters. Each input byte is 8 bits, but each Base64 character represents only 6 bits of data. The ratio of output to input is 4/3 = 1.333, meaning a 33% size increase. This overhead is the cost of representing binary data in a text-safe format.

What does the equals sign at the end mean?

The = character is padding. Base64 processes input in 3-byte groups. If the input length isn't divisible by 3, padding is added: = means one byte of padding was needed, == means two bytes. This tells the decoder exactly how many bytes to discard when reconstructing the original data.

What's the difference between Base64 and Base64URL?

Standard Base64 uses + and / as characters 62 and 63, plus = for padding. Base64URL replaces + with - and / with _, and padding is often omitted. This makes the output safe for use in URLs, filenames, and other contexts where +, /, and = have special meaning.

Can I Base64 encode any type of file?

Yes. Base64 works on raw bytes, so any file — images, PDFs, executables, archives — can be encoded. The decoder will produce the exact same bytes as the original. However, for large files, the 33% size overhead makes Base64 impractical compared to binary transfer methods.