DevToolsHub
← Back to Home

Base64 Encoding & Decoding: What Every Developer Needs to Know

June 19, 20267 min readTutorial

Base64 is one of those technologies that every developer encounters but few deeply understand. It shows up in data URLs, JWT tokens, email attachments, authentication headers, and countless API specifications. But what exactly is Base64, and why is it so widely used? This guide covers everything you need to know.

What Is Base64?

Base64 is a binary-to-text encoding scheme that represents binary data in an ASCII string format. It uses 64 printable characters — A-Z, a-z, 0-9, +, and / (plus = for padding) — to encode arbitrary binary data. The name "Base64" comes from the 64-character alphabet.

Crucially, Base64 is not encryption. It is an encoding, like Morse code or hexadecimal. Anyone can decode Base64 back to the original data. Never use Base64 to protect sensitive information — use proper encryption (AES, RSA) for that.

When Do Developers Use Base64?

1. Data URLs in HTML/CSS

Inline images and fonts can be embedded directly in HTML using data URLs. The image binary is Base64-encoded and embedded in the src attribute:

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

This eliminates an HTTP request but increases the page size by about 33% (Base64's overhead). Use it sparingly — typically only for very small images (under 1 KB).

2. JWT Tokens

JSON Web Tokens (JWTs) use Base64url encoding (a URL-safe variant) for their three parts: header, payload, and signature. Each part is Base64url-encoded JSON. The JWT decoder on DevToolsHub actually uses Base64 decoding under the hood to parse tokens.

3. HTTP Basic Authentication

The Authorization: Basic header encodes the username:password pair in Base64:

// "admin:secret123" → Base64
Authorization: Basic YWRtaW46c2VjcmV0MTIz

4. Email Attachments (MIME)

Email protocols were designed for text. Binary attachments (images, PDFs, documents) are Base64-encoded within MIME parts so they can traverse SMTP servers reliably.

How Base64 Works (Briefly)

Every 3 bytes (24 bits) of input data are split into four 6-bit chunks. Each 6-bit value (0-63) maps to a character in the Base64 alphabet. If the input length is not divisible by 3, padding = characters are added to make the output length a multiple of 4.

This means Base64 encoding increases data size by roughly 33% — every 3 bytes become 4 ASCII characters.

Common Pitfalls with Browser Base64

The browser APIs btoa() (binary to ASCII) and atob() (ASCII to binary) have a notorious limitation — they only work with Latin-1 (single-byte) characters. Trying to encode a Unicode string like "你好" directly with btoa() throws a DOMException.

The fix involves a two-step encode/decode using URI encoding:

// Encode Unicode string to Base64
btoa(unescape(encodeURIComponent("你好世界")));
// → "5L2g5aW95LiW55WM"

// Decode Base64 back to Unicode string
decodeURIComponent(escape(atob("5L2g5aW95LiW55WM")));
// → "你好世界"

A good Base64 encoder/decoder handles this automatically — just paste your text and it works, no matter the encoding.

Base64 vs Base64url

Standard Base64 uses + and /, which are problematic in URLs and filenames. Base64url replaces them with - and _, and strips trailing = padding. JWT tokens and many modern APIs use Base64url.

Key Takeaways

  • Base64 is an encoding, not encryption — do not use it to protect secrets
  • It adds ~33% overhead, so avoid it for large data transfers
  • Browser btoa() does not support Unicode — use the encodeURIComponent workaround
  • Base64url is the URL-safe variant used in JWT and modern web standards
  • Use a dedicated online tool when you need quick encode/decode during development

Next time you see a long string of seemingly random characters ending in =, you will know exactly what it is — Base64, the universal binary-to-text bridge.