What Is Base64?
Base64 is a binary-to-text encoding scheme that converts arbitrary binary data into a string of 64 printable ASCII characters. The name comes directly from the 64 characters used: A–Z, a–z, 0–9, and the symbols + and /, plus = for padding.
It is not encryption. It is not compression. It is purely a way to represent binary data — bytes that might include unprintable control characters — as safe, printable text that can travel through any text-based system without corruption.
If you have ever seen a string that looks like eyJhbGciOiJIUzI1NiJ9 and wondered what it is, that is Base64 in the wild — specifically, the header of a JWT token.
Why Does Base64 Exist?
The reason Base64 exists comes down to history. Many early data transfer protocols — email (SMTP), HTTP headers, URLs, XML — were designed to handle ASCII text only. Raw binary data contains byte values (0–31) that were interpreted as control characters by these protocols. Sending a JPEG image directly through SMTP would corrupt it because the bytes representing pixel data could match the byte sequences for "end of message" or "carriage return."
Base64 solves this by converting binary data into a subset of ASCII characters that are universally safe. Every character in the Base64 alphabet is printable and unambiguous across all text-handling systems built in the past 50 years.
Today, even though modern protocols handle binary data natively (HTTP/2 is binary by design, for example), Base64 remains everywhere because so many APIs, file formats, and authentication systems were built on top of older text-based conventions.
How Does the Encoding Work?
Base64 takes every 3 bytes of input (24 bits) and splits them into four 6-bit groups. Each 6-bit group can represent values 0–63, which map to one of the 64 characters in the Base64 alphabet.
Example: the ASCII string "Man" encoded to Base64:
- "M" = 77 =
01001101 - "a" = 97 =
01100001 - "n" = 110 =
01101110 - Combined 24 bits:
010011010110000101101110 - Split into 6-bit groups:
010011010110000101101110 - Values: 19, 22, 5, 46
- Base64 chars: T, W, F, u → "TWFu"
This is why Base64 output is always roughly 33% larger than the original input — 3 bytes become 4 characters. If the input is not a multiple of 3 bytes, = padding characters are added to make the output length a multiple of 4.
Common Use Cases
- Email attachments — MIME encoding uses Base64 for binary attachments. Every PDF or image you attach to an email passes through Base64 encoding before being sent.
- Data URIs — embedding images directly in CSS or HTML:
data:image/png;base64,iVBOR.... Useful for small icons to eliminate HTTP requests. - JWT tokens — the header and payload sections of JSON Web Tokens are Base64URL encoded (a URL-safe variant).
- API authentication — HTTP Basic Auth encodes
username:passwordin Base64:Authorization: Basic dXNlcjpwYXNz. - Storing binary in JSON or XML — JSON has no binary type. Base64 is the standard convention for embedding binary data (images, PDFs, cryptographic keys) inside JSON payloads.
- Cryptographic keys and certificates — PEM files (the
.pemformat for SSL certificates) are Base64-encoded DER binary data wrapped in-----BEGIN CERTIFICATE-----headers.
Base64 vs Base64URL
Standard Base64 uses + and /, which are special characters in URLs (+ means space in query strings; / is a path separator). Base64URL replaces them with - and _, making the output safe for use in URLs, HTTP headers, and filenames without percent-encoding.
Base64URL also typically omits the = padding characters, since they are meaningless in the contexts where Base64URL is used. JWT tokens use Base64URL encoding — which is why you will never see a / inside a JWT header or payload section.
Security Considerations
This cannot be stated strongly enough: Base64 provides zero security. It is trivially reversible — anyone who sees a Base64 string can decode it in milliseconds using any programming language or online tool.
The most dangerous misconception in software development is that Base64-encoded data is in some way protected or hidden. Consider the HTTP Basic Auth example: Authorization: Basic dXNlcjpwYXNz. That Base64 string decodes to user:pass — completely readable to anyone who intercepts the request. This is why Basic Auth should only ever be used over HTTPS.
Similarly, JWT payloads are Base64URL encoded — not encrypted. Anyone who has a JWT can read everything in its payload. Never put passwords, credit card numbers, or other secrets in a JWT payload.
For actual data protection, use encryption (AES-256-GCM for symmetric, RSA or ECDH for asymmetric). Base64 is for transport encoding, not security.
Performance Considerations
The 33% size overhead of Base64 matters in certain contexts. For data URIs, embedding large images as Base64 increases HTML/CSS file size and can slow initial page render. The rule of thumb: only use data URIs for images smaller than 1–2KB. For larger assets, serve them as separate files so they can be cached independently.
In API design, avoid Base64-encoding large binary blobs in JSON responses. Instead, provide a URL to the binary resource and let the client fetch it separately. This keeps your JSON response sizes manageable and allows the binary asset to be CDN-cached.
Try It Yourself
Use PureFormatter's Base64 tool to encode and decode Base64 strings instantly in your browser. No data ever leaves your machine — everything is processed client-side. This makes it safe to use for decoding JWT tokens, authentication headers, and other potentially sensitive values.
