What Is Base64 Encoding? A Practical Explanation for Non-Cryptographers

Base64 turns any data (text, images, files) into a string made from 64 safe characters: the letters A–Z and a–z, the digits 0–9, and + and /, with = used for padding. That is all it does. It exists because many systems were built to carry plain text, and raw binary data breaks them. Base64 is the standard way to move binary data through text-only channels intact. This guide explains how it works, where you'll meet it, the variants you need to know about, and the misconception that causes real security incidents.

How Base64 works

Computers store everything as bytes of 8 bits. Base64 takes the data 3 bytes (24 bits) at a time, splits those 24 bits into four 6-bit groups, and maps each group (a number from 0 to 63) to one of the 64 characters. Three bytes in, four characters out.

The word Man is a classic example: its three bytes become the four characters TWFu. When the input isn't a multiple of three bytes, the output is padded with =: Hi becomes SGk=, and hello becomes aGVsbG8=.

Two consequences follow directly:

• Base64 makes data about 33% bigger, because every 3 bytes become 4 characters.
• Valid Base64 has a recognisable shape: only those 64 characters, a length divisible by four (when padded), and at most two = signs at the end.

Where you'll meet it

• Email attachments: email is a text protocol, so every attachment travels as Base64 under the hood. Look at the raw source of an email with an attachment and you will see screens of it.
• Data URLs: small images embedded directly in HTML or CSS, as in data:image/png;base64,iVBORw0KGgo..., saving a separate request for tiny icons.
• APIs and JSON: JSON can only hold text, so files, images and binary data are Base64-encoded inside it.
• JWTs (JSON Web Tokens): the header and payload of a login token are Base64url-encoded JSON, separated by dots.
• HTTP Basic authentication: the header Authorization: Basic YWRtaW46c2VjcmV0 is just admin:secret in Base64, which leads to the big misconception.

Base64 is not encryption

Encoding is reversible by anyone, instantly, with no key. A Base64 string looks scrambled, but it hides nothing. Decoding YWRtaW46c2VjcmV0 back to admin:secret takes one click.

This misunderstanding causes real breaches: passwords "protected" with Base64 in config files, API keys "hidden" in Base64 in mobile apps, and personal data in Base64 in URLs, all of it readable by anyone who looks. HTTP Basic authentication is only safe because the connection itself is encrypted with HTTPS.

• To keep data secret, use encryption, such as password-protecting a document with the Protect PDF tool or an encrypted file transfer.
• To fingerprint data or check it hasn't changed, use a hash. See the Hash Generator and our guide to MD5 vs SHA-256.
• To transport binary data through text, use Base64.

Base64 vs Base64url

Standard Base64 uses + and /, which have special meanings in URLs and file names. The Base64url variant swaps them for - and _ and often drops the = padding. JWTs and many web APIs use it. If a string with - or _ won't decode, replace those with + and /, add = until the length is a multiple of four, and try again.

A related point: Base64 isn't the same as URL encoding. URL encoding (%20 for a space) makes text safe inside a URL; our guide to URL encoding covers it.

Encode or decode a string

1. Open the Base64 Encoder/Decoder.
2. Paste plain text to encode, or a Base64 string to decode.
3. Copy the result.

It handles Unicode correctly, so accented letters, Indian scripts and emoji survive the round trip (café encodes as Y2Fmw6k=, from its UTF-8 bytes). It runs entirely in your browser, which matters because the strings people decode are often tokens and credentials.

Reading a JWT

A JWT looks like xxxxx.yyyyy.zzzzz. Decode the first part (header) and second part (payload) separately to see the claims inside, such as the user ID, roles and expiry time (exp, a Unix timestamp). Note what this shows: anyone holding a token can read its contents. That is by design. What they can't do without the secret key is change the contents and produce a valid signature, which is the third part. Never put secrets in a JWT payload.

Why decoded output sometimes looks like garbage

• It is binary data, such as an image, PDF or compressed file, which has no readable text form. Its first characters often give it away: iVBORw0KGgo is a PNG, /9j/ a JPEG, JVBERi0 a PDF.
• It is Base64url, so swap - and _ back as described above.
• It is cut off or has stray spaces or line breaks from copying. Check the length and characters.
• It isn't Base64 at all, but a hash or an encrypted value, which also look like random characters.

When not to use Base64

Because it adds a third to the size, Base64 is a good deal for small payloads and a bad one for big files. Embed a 2 KB icon as a data URL by all means; link to a 2 MB photo instead of embedding it. For APIs, sending large files as multipart uploads or direct links avoids the overhead and the memory cost of encoding.

Frequently asked questions

Is Base64 safe to use for passwords?

No. It provides zero protection. Passwords must be hashed with a password-hashing function such as Argon2 or bcrypt.

Why does Base64 end with = signs?

Padding. When the input length isn't a multiple of three bytes, one or two = signs fill out the last group of four characters.

Can Base64 contain line breaks?

Some formats (email, PEM certificates) wrap Base64 at 64 or 76 characters per line. Decoders generally ignore those line breaks.

Is Base64 the same in every language?

Standard Base64 is identical everywhere. Differences come from the variant (standard vs url-safe) and from how text is turned into bytes, which should be UTF-8.