Base64 in five minutes: what it does and why it is not encryption

You have probably seen strings like SGVsbG8= in an API response, a data URL, or an email attachment.

They look secret. They are not.

Base64 is an encoding, not an encryption method. Its job is to represent binary data using ordinary text characters so that the data can travel safely through systems designed for text.

The short version

Base64 takes bytes and represents them with a 64-character alphabet:

A-Z, a-z, 0-9, +, and /

A URL-safe variation replaces the last two characters with - and _.

The important point is that Base64 does not hide information. Anyone who receives the encoded string can decode it without a password or secret key.

A tiny example

Take the text:

Hello

Its Base64 representation is:

SGVsbG8=

I verified this example with the Base64 Encoder and Decoder on All Tools Verse.

If you decode SGVsbG8=, you get Hello back. Nothing was protected. The bytes were only written in another form.

How the conversion works

Base64 processes data in groups of three bytes.

Three bytes contain 24 bits. Base64 divides those 24 bits into four groups of 6 bits. A 6-bit value has 64 possible combinations, so each group maps to one character in the Base64 alphabet.

That gives us this relationship:

3 input bytes -> 4 Base64 characters

This is also why Base64 usually makes data larger. Four output characters are needed to represent three input bytes, so the encoded result is roughly 33 percent larger before line breaks or other formatting.

Base64 is useful for compatibility, not compression.

Why does Base64 sometimes end with =?

Base64 works most cleanly with groups of three input bytes. But input lengths are not always divisible by three.

The = character is padding. It tells the decoder that the final group did not contain a complete set of three bytes.

In the Hello example, the final = is padding. Depending on the input length, you may see:

• no padding
• one padding character
• two padding characters

Some systems omit padding, especially in URL-safe Base64. A decoder may need to restore it before processing the string.

Where Base64 is useful

Base64 is a practical choice when binary data must pass through a text-only channel.

Common examples include:

• email attachments using MIME
• small images embedded in CSS or HTML data URLs
• binary fields inside JSON or XML
• certificates, keys, and other PEM-formatted data
• compact payloads passed between systems that expect text
• short test fixtures in documentation or source code

It is often convenient, but it is not always efficient. For large files, sending the original binary data is usually better than increasing its size with Base64.

Where Base64 is the wrong tool

Do not use Base64 as a security layer.

It is not suitable for:

• storing passwords
• protecting API keys
• hiding access tokens
• concealing personal information
• replacing encryption in transit or at rest

A Base64 value may look unreadable at a glance, but decoding it is immediate and requires no special access.

Passwords should be processed with a password hashing algorithm designed for that job. Sensitive data should use appropriate encryption, access controls, and secure transport such as HTTPS.

Encoding text correctly

Text must first become bytes. Modern applications normally use UTF-8 for this step.

That matters when the input includes:

• emoji
• accented characters
• Greek text
• CJK characters
• symbols outside basic ASCII

If one side encodes text as UTF-8 and the other side decodes the bytes with a different character set, the result can be corrupted even when the Base64 conversion itself is correct.

So a complete agreement between two systems includes both:

1. the Base64 variant
2. the character encoding used before and after Base64

Standard Base64 vs URL-safe Base64

Standard Base64 uses + and /. Those characters can have special meanings inside URLs and file names.

URL-safe Base64 replaces them:

+ becomes -
/ becomes _

Padding may also be removed. If an encoded value will appear in a URL, cookie, or token format, check which variant the receiving system expects.

A practical checklist

When Base64 data does not decode correctly, check:

• Is it standard or URL-safe Base64?
• Is padding missing?
• Was the original text encoded as UTF-8?
• Did a URL parser replace the plus sign with a space?
• Is the string incomplete or wrapped across lines?
• Are you decoding Base64 once when the source encoded it twice?

These checks solve a surprising number of Base64 bugs.

The mental model to keep

Base64 is a transport format.

It turns bytes into portable text, adds some size, and can be reversed by anyone. It is useful when a system needs text-safe data, but it provides no secrecy on its own.

For a longer comparison of related formats, see Base64, Base32 and Base58 Encoding Explained.

I build All Tools Verse, a directory of 1,000+ browser-based tools. This article is original DEV content, and the linked encoder was used to verify the example above.