What Is Base64 Encoding?
Base64 encodes binary data as ASCII text using 64 safe characters, enabling transport in JSON, email, and URLs.
Quick answer
Base64 represents binary data using 64 printable ASCII characters (A–Z, a–z, 0–9, +, /) plus padding `=` as needed. It is encoding, not encryption—anyone can decode it. Common uses: embedding small images in HTML/CSS data URLs, carrying binary in JSON strings, and email MIME attachments.
Overview
APIs and web platforms often require text-safe payloads even when content is inherently binary—images, PDF bytes, or encrypted ciphertext. Base64 transforms arbitrary bytes into a larger ASCII string that survives JSON, XML, and email systems that are not binary-clean. The size overhead is roughly 33 percent, which matters for large files but is acceptable for thumbnails, tokens, and short binary blobs. Developers also confuse Base64 with hashing or encryption; decoding is trivial with public tools, so never treat Base64 alone as security. Understanding alphabet variants (URL-safe Base64 replacing +/ ) prevents subtle production bugs in query strings and JWT segments.
How Base64 encoding works
Input bytes split into 6-bit groups, each mapped to one of 64 characters. Three bytes (24 bits) become four Base64 characters. Remainder bytes get padding with one or two `=` signs so decoders restore original length.
Decoding reverses the mapping, reconstructing binary from character sequence. Invalid characters or incorrect padding produce decode errors in strict libraries—use validated test vectors when implementing pipelines.
Common developer use cases
Data URLs in HTML/CSS: `data:image/png;base64,...` embeds small icons without separate HTTP requests. JSON APIs carry file uploads as Base64 strings when multipart form is unavailable.
Basic authentication headers encode `username:password` (prefer OAuth in production). Email MIME encodes attachments. Some databases store binary columns as Base64 in export dumps—convenience, not compression.
Standard vs URL-safe Base64
Standard Base64 uses `+` and `/`, which need URL encoding in query parameters. URL-safe variant replaces with `-` and `_`, often omitting padding in JWT and cookie contexts per spec.
Mixing variants breaks decode. Document which alphabet your API expects; convert before placing Base64 in URL paths or query values alongside percent-encoding rules.
Encoding is not encryption or hashing
Base64 is reversible encoding with public algorithms—do not store secrets 'protected' by Base64 alone. Combine TLS in transit, proper encryption at rest, and secret management for credentials.
Developers sometimes Base64-wrap already-encrypted bytes for transport—that is fine if encryption happened first. Order matters: encrypt then encode for wire format; decode then decrypt on receipt.
Size, performance, and alternatives
33% overhead plus decode CPU makes Base64 poor for large media at scale—prefer binary multipart uploads, object storage signed URLs, or dedicated CDN paths for big assets.
For small inline assets and config snippets, overhead is negligible. gzip then Base64 rarely helps text JSON; binary compression before Base64 can help email size limits on attachments.
Examples
Hello encoding
ASCII 'Hello' encodes to 'SGVsbG8='—demonstrates padding on non-multiple-of-three length input.
JSON image field
API returns `{ "thumbnail": "iVBORw0KGgo..." }` where value is Base64 PNG bytes decoded client-side to blob URL.
Common mistakes and edge cases
- Treating Base64 as encryption for passwords or API keys.
- Using standard Base64 unencoded in URL query strings.
- Forgetting charset—encode UTF-8 bytes before Base64, not raw Unicode code point strings inconsistently.
- Assuming decode success means valid file—validate magic bytes after decode.
Related resources
Related tools
Last reviewed: 2026-05-23