What Base64 actually is — and what it is not
Base64 is an encoding scheme, not encryption. This distinction matters more than it might seem. People sometimes Base64-encode passwords or API keys thinking it provides some protection. It does not. Anyone who has the encoded string can decode it in under a second with a single line of code. Base64 provides zero security. Its only purpose is to represent binary data as printable ASCII text so it can travel safely through channels designed for text.
That is a genuinely useful problem to solve. HTTP headers are text. Email is text. JSON has no binary type. When you need to move binary data — images, cryptographic keys, file content — through one of these text-only channels, Base64 is how you do it.
How it works
Base64 works by taking three bytes of input (24 bits) and encoding them as four printable characters. It draws from an alphabet of 64 characters: A–Z, a–z, 0–9, +, and /. Each character represents 6 bits (since 2^6 = 64). Three bytes of 8 bits each = 24 bits = four 6-bit groups = four Base64 characters.
Take the word "Man":
M= ASCII 77 =01001101a= ASCII 97 =01100001n= ASCII 110 =01101110
Concatenated into 24 bits: 010011 010110 000101 101110
Each 6-bit group maps to: 19=T, 22=W, 5=F, 46=u → result is TWFu.
When the input length is not a multiple of three bytes, = padding is added at the end — one = if one remainder byte, two = if two. You will recognise this from JWT tokens that end in one or two equals signs.
Base64URL — the URL-safe variant you see in JWTs
Standard Base64 uses + and /, both of which have special meaning in URLs. Base64URL is a small variation: it replaces + with - and / with _, and drops the trailing = padding. Every JWT token uses Base64URL encoding for its header and payload — that is why you can paste one into a decoder and read the claims directly.
If you are working with tokens, OAuth flows, or anything that goes in a URL or HTTP header, make sure you are using a Base64URL encoder, not standard Base64. The difference looks small but causes subtle, hard-to-debug errors when the wrong variant ends up in a signature comparison.
Where you actually encounter Base64
Data URLs are the most visible use. You have probably seen src="data:image/png;base64,iVBORw0KGgo..." in generated HTML — that is an entire PNG file inlined as a Base64 string. It eliminates one HTTP request, which makes sense for small icons. For anything larger than a few kilobytes, it is the wrong choice — the 33% size overhead and loss of browser caching make it slower than a separate file request.
HTTP Basic Authentication sends credentials as Base64 in every request: Authorization: Basic cGFua2FqOm15cGFzc3dvcmQ=. Decoding that gives pankaj:mypassword in plain text. This is why Basic Auth should only ever be used over HTTPS — the encoding provides no protection at all, it just makes the header slightly less readable at a glance.
Environment variables and secrets — TLS certificates, private keys, and other binary blobs are often stored as Base64 strings in CI/CD pipelines and container environments because environment variables are text-only. This is fine, but remember: if someone gets access to your CI environment or deployment config, decoding the Base64 gives them the raw key. The Base64 is not protection.
The size trade-off
Base64 increases data size by roughly 33%. Three input bytes become four output characters. For a 100 KB PNG, that is a 133 KB Base64 string. For large files, this overhead becomes significant — a 5 MB image embedded as a data URL adds 6.7 MB to your HTML, bypasses browser caching entirely, and cannot be served with its own cache headers or CDN rules. Serve large binary files as separate HTTP resources and use Base64 only for small assets where the round-trip savings outweigh the size increase.
Decoding is not always text
One thing that trips up developers: Base64 decodes to bytes, not necessarily to valid text. If you Base64-encoded a PNG and then try to decode it as a UTF-8 string, you get garbage. Always know what type of data is inside the encoding before you decide how to handle the decoded output. Decoding a JWT payload to a string works because the payload was JSON to begin with. Decoding an image to a string does not work for the same reason.