Base64 Explained: What It Is and When to Use It
October 4, 2026
2 readsIf you've worked with APIs, email attachments, or web pages, you've run into Base64: long strings of letters and numbers that end in one or two equals signs. People often assume it's a kind of encryption. It isn't, and that misunderstanding causes real security problems. Here's what Base64 is, what it's good for, and where it doesn't belong.
What Base64 does
Computers store all data as bytes, and a byte can have any of 256 values. But many systems that carry data, such as email, JSON, URLs and HTML attributes, were designed for plain text. Some byte values confuse them. A stray control character can end a line, break a field, or get mangled in transit.
Base64 solves this by rewriting any data using only 64 safe characters: the uppercase letters A to Z, lowercase a to z, the digits 0 to 9, and + and /. The result can travel anywhere that text can.
How it works, briefly
Base64 reads your data three bytes at a time. Three bytes is 24 bits, which it splits into four groups of 6 bits. Each 6-bit group is a number from 0 to 63, which is looked up in the 64-character alphabet. So three bytes in become four characters out.
When the data isn't an exact multiple of three bytes, the output is padded with = signs at the end. That's why you often see one or two equals signs closing a Base64 string.
For example, the text Hi becomes SGk=, and Hello becomes SGVsbG8=. You can try this yourself in the Base64 Encoder/Decoder.
The costs: about a third bigger
Because three bytes become four characters, Base64 makes data roughly 33% larger. A 300 KB image becomes about 400 KB as Base64 text. That's the price of being text-safe, and it's the reason you shouldn't use it for everything.
Where Base64 is the right tool
Email attachments. Email's underlying protocol is text-based, so attachments are Base64-encoded in transit and decoded again by your mail client. You never see it happen.
Embedding small images in code. A data URL lets you put an image straight into HTML or CSS: data:image/png;base64,.... For a tiny icon, this saves a network request. The Image to Base64 tool produces one from any picture, and Base64 to Image converts it back.
Sending binary data in JSON. JSON has no binary type, so APIs commonly carry files, signatures or keys as Base64 strings.
Tokens and credentials. HTTP Basic authentication sends username:password encoded in Base64. And a JWT is three Base64URL-encoded parts joined by dots, as explained in what's actually inside a JWT. Base64URL is a variant that swaps + and / for - and _, so the string is safe to put in a URL.
Where Base64 is the wrong tool
As security. Anyone can decode Base64 instantly, with no key. If a password, API key or personal detail is "hidden" in Base64, it isn't hidden at all. Real protection needs proper encryption, and passwords should be hashed, not encoded. Our post on what actually makes a password strong covers the basics.
For large images on web pages. A big image as Base64 inside your HTML makes the page heavier, can't be cached separately from the page, and delays rendering. Keep large images as separate files, and optimize them first with Image Compressor. Our practical guide to image tools covers that workflow.
To save space. It does the opposite.
Common problems and how to fix them
- Broken characters after decoding. If the original text used accents or non-Latin characters, make sure it was encoded as UTF-8 before the Base64 step, and decoded the same way afterwards.
- "Invalid character" errors. Base64 uses
+and/, while Base64URL uses-and_. Mixing them up is the usual cause. Also check for stray spaces or line breaks that got copied along with the string. - Missing padding. Some systems drop the trailing
=signs. Many decoders accept that, and some don't. Add the padding back if yours complains. - A string that decodes to garbage. Not all Base64 is text. If the original was an image or a file, decoding gives raw bytes, not readable words.
A quick way to recognize it
Base64 strings are made only of letters, digits, + and / (or - and _), often ending in =, and their length is a multiple of four. If you see something like that in an API response or a config file, it's very likely Base64. If it starts with eyJ, it's almost certainly the start of a JWT, because {" encodes to eyJ.
A short checklist for developers
- Is the channel text-only and the data binary? Base64 helps.
- Is the data large? Think twice, since you pay a third more.
- Is the goal secrecy? Base64 is the wrong tool. Use encryption.
- Is the string going into a URL? Use the URL-safe variant, and also see URL Encoder/Decoder for percent-encoding.
- Always specify the character encoding (UTF-8) for text.
The short version
Base64 is a way to carry bytes through systems that only understand text, at the cost of making data about a third larger. It's invaluable for email, data URLs and JSON, and useless as protection. Remember that it can be reversed by anyone, and you'll avoid the most common Base64 mistake.