What Base64 Is, When to Use It and When Not To

Base64 shows up everywhere: in email attachments, in API headers, in config files, in the middle of a JSON Web Token. It is also one of the most misunderstood tools in a developer's kit, because the output looks scrambled and people assume it must be protecting something. It is not. This guide explains what Base64 is for, what it costs, and how to decide whether it belongs in what you are building.

What Base64 actually does

Computers store everything as bytes, but many channels only handle plain text safely. Email bodies, JSON strings, HTML attributes and HTTP headers can mangle or reject arbitrary bytes. Base64 solves this by re-expressing any sequence of bytes using only 64 safe characters: the letters A to Z and a to z, the digits 0 to 9, plus + and /. A trailing = is used as padding.

It works on groups of three bytes (24 bits) and splits them into four 6-bit pieces. Each piece maps to one character. That is the whole algorithm, and it has no key and no secret. Anyone who sees the output can reverse it in a second.

When you type text into the Base64 encoder, it first converts the text to UTF-8 bytes and then encodes those bytes. That detail matters for non-English text, as the examples below show.

Worked examples

Here are real input and output pairs you can reproduce in the encoder and the Base64 decoder:

Input text	Base64 output	Characters in	Bytes (UTF-8)	Characters out
Hello	SGVsbG8=	5	5	8
café	Y2Fmw6k=	4	5	8
ravi:S3cret!	cmF2aTpTM2NyZXQh	12	12	16
Devanagari word नमस्ते	4KSo4KSu4KS44KWN4KSk4KWH	6	18	24

Look at the second row. The word “café” has four characters but five bytes, because é takes two bytes in UTF-8. Base64 sees bytes, not characters, so the output length depends on the byte count. The Hindi example is the extreme case: six characters become 18 bytes and then 24 Base64 characters.

Now the third row. If you decode cmF2aTpTM2NyZXQh you get ravi:S3cret!, a username and password. This is exactly how HTTP Basic authentication builds its header: the word Basic, a space, then the Base64 of username:password. It is encoding, so anyone who can see that header can read the password. Basic authentication is only acceptable over HTTPS, and even then it is a weak design for anything important.

The size cost: about one third more

Three bytes become four characters, so output is always about 33% larger than the input, rounded up to a multiple of four characters:

Original size	Base64 size
3 bytes	4 characters
300 bytes	400 characters
3,000 bytes	4,000 characters
30,000 bytes	40,000 characters

For short strings this is irrelevant. For a 30 KB image embedded in a page, you pay roughly 10 KB extra, and the browser cannot cache that image separately from the page that contains it. That is the trade-off behind the data URI technique (data:image/png;base64,...): it saves an HTTP request, which can help for a tiny icon, but it bloats your HTML or CSS and defeats caching for anything larger. A sensible rule of thumb is to inline only very small assets and serve everything else as normal files.

When Base64 is the right choice

• Putting binary data inside text formats. JSON has no binary type, so a small file or key is often sent as a Base64 string.
• Email attachments. MIME encodes attachments as Base64 so they survive mail systems built for text.
• Basic authentication headers, as described above, where the format is dictated by the HTTP standard.
• Configuration values with awkward characters. Kubernetes Secret manifests, for example, store values Base64-encoded. That is about representation, not protection: anyone with read access to the Secret can decode it.
• Tiny inline assets such as a small icon in CSS.

When Base64 is the wrong choice

• Hiding or protecting data. It is not encryption. Passwords, API keys and personal data need real encryption or, better, should not be stored in readable form at all. If you find credentials Base64-encoded in a repository or log, treat them as exposed and rotate them.
• Compressing data. It does the opposite and makes data bigger.
• Making a string safe for a URL. Standard Base64 contains +, / and =, all of which have special meaning in URLs. Use the right tool for the job, covered next.
• Large files in an API. Sending a multi-megabyte file as a Base64 string inflates it by a third and forces the whole thing into memory. Upload it as a file instead.

Base64 versus URL encoding versus URL-safe Base64

These three get confused constantly, and they solve different problems.

• Standard Base64 turns bytes into text. It is what the Base64 encoder produces.
• URL encoding (percent-encoding) keeps ordinary text, but replaces unsafe characters with % codes so it can sit inside a web address. For example, price=₹500&q=a b becomes price%3D%E2%82%B9500%26q%3Da%20b. Use the URL encoder for this. The text stays readable; only the special characters change.
• URL-safe Base64 is a variant that swaps + for - and / for _, and often drops the = padding. As an illustration, the three bytes with values 251, 255, 254 encode to +//+ in standard Base64 and -__- in the URL-safe form. JSON Web Tokens use this variant for their sections, which is why the JWT decoder exists as a separate tool: it converts the URL-safe characters back before decoding.

The practical consequence: our encoder and decoder use the standard alphabet. If a string contains - or _, it is URL-safe Base64, and you should replace those with + and / before pasting it into the decoder. Likewise, if you need URL-safe output from the encoder, make those two swaps yourself and remove the padding if your system expects that.

A quick decision framework

1. Do I need the data to be secret? Base64 will not help. Use encryption, or do not store it.
2. Is the channel text-only and the data binary or full of special characters? Base64 is a reasonable fit.
3. Is the data going into a URL? Use percent-encoding for text, or URL-safe Base64 for bytes.
4. Is the data large? Avoid Base64 and send the file directly.
5. Is a standard demanding it? (Basic auth, MIME, JWT.) Then use it, and understand that it offers no secrecy.

Troubleshooting a string that will not decode

• Remove prefixes such as Basic or data:image/png;base64, before pasting.
• Check for stray spaces, line breaks or quotation marks copied along with the text.
• A truncated copy is a very common cause. A complete padded string has a length that is a multiple of four.
• If the decoded result looks like garbage, the data may be binary (an image or PDF), not text. That does not mean decoding failed.

Limits: what this does not cover

The encoder and decoder on this site work on text you type or paste, entirely in your browser. They do not encode files or images directly, they do not accept URL-safe input without you converting it first, and they do not validate or sign anything. They also cannot tell you whether a decoded value is safe: decoded content can be anything, so do not run or open data you do not recognise. If you work with tokens, remember that decoding a JWT only reads it. It does not verify that the token is genuine; that requires the issuer's key on a server.

Base64 is a transport format. Used for that purpose it is simple and reliable. Used as security, it gives a false sense of protection, which is worse than having none.