Base64 Encoding Explained: What It Is and When to Use It

You have probably seen strings like SGVsbG8sIHdvcmxkIQ== in an email source, a configuration file or an API response. That is Base64 encoding: a way of representing any data, including images and binary files, using only 64 safe, printable characters. It is everywhere in computing, it is simple, and it is frequently misunderstood as a form of security. It is not.

The problem Base64 solves

Many systems were designed to carry text, not arbitrary bytes. Email, for instance, was built around 7-bit text; HTTP headers, JSON documents, XML files and URLs all have characters that are forbidden or have special meanings. Raw binary data, such as a PDF or a PNG, contains every possible byte value, including control characters and line breaks, which can be altered or rejected by text-based systems.

Base64 converts binary data into a restricted alphabet that survives these systems untouched, then converts it back exactly at the other end.

How Base64 encoding works

The standard alphabet, defined in RFC 4648, has 64 characters: A–Z, a–z, 0–9, + and /. Since 64 is 2 to the power of 6, each character represents exactly 6 bits.

The process works on groups of 3 bytes (24 bits) at a time:

Take 3 bytes of input: 24 bits.
Split them into four 6-bit groups.
Map each 6-bit value (0–63) to a character in the alphabet.

Worked example with the text Man:

Characters:   M         a         n
ASCII bytes:  77        97        110
Binary:       01001101  01100001  01101110
Regrouped:    010011 010110 000101 101110
Values:       19     22     5      46
Base64:       T      W      F      u        →  "TWFu"

When the input length is not a multiple of 3, the output is padded with = characters so its length is a multiple of 4. One leftover byte produces two characters plus ==; two leftover bytes produce three characters plus =. That is why many Base64 strings end in one or two equals signs.

The size cost

Because every 3 bytes become 4 characters, Base64 output is about 33% larger than the input, plus a little more if line breaks are added (MIME email wraps lines at 76 characters). That overhead is the main reason not to use Base64 when you do not need it.

Where Base64 is used

Email attachments. MIME encodes attachments in Base64 so they travel safely through mail servers. Look at the raw source of any email with an attachment and you will see Content-Transfer-Encoding: base64.
Data URLs. Small images or fonts can be embedded directly in HTML or CSS: <img src="data:image/png;base64,iVBORw0KGgo...">. This saves a request but cannot be cached separately, so it suits only very small files.
HTTP Basic authentication. The header Authorization: Basic dXNlcjpwYXNz is simply user:pass in Base64. Anyone who sees the header can decode it, which is why Basic auth must only be used over HTTPS.
JSON Web Tokens (JWT). The header and payload are Base64url-encoded JSON. They are readable by anyone; the signature only proves they have not been altered.
APIs that need to include files or binary data inside JSON.
Certificates and keys. PEM files (the ones starting -----BEGIN CERTIFICATE-----) are Base64-encoded binary data.
DKIM records in DNS, which publish an email signing public key in Base64. You can view yours with an SPF, DKIM and DMARC checker.

Base64url: the URL-safe variant

The standard alphabet's + and / have special meanings in URLs and file names, and = is used in query strings. The Base64url variant, also defined in RFC 4648, replaces + with - and / with _, and padding is often omitted. JWTs and many web APIs use it. If a decoder complains about invalid characters, check whether you have the standard or URL-safe form.

Base64 is not encryption

This point deserves emphasis. Base64 has no key and no secret. Anyone can decode it instantly. Encoding a password, an API key or personal data in Base64 hides it from nobody. Real-world consequences include:

Credentials in Base64 inside configuration files, scripts or Kubernetes secrets that are readable by anyone who can see the file.
"Obfuscated" tokens in URLs or mobile apps that reveal customer IDs or internal data when decoded.
Malware that uses Base64 to hide commands from casual inspection, which is why security tools look for long encoded strings in scripts.

If data needs to be secret, encrypt it with a proper algorithm and manage the keys carefully, and protect it in transit with TLS.

Encoding and decoding in practice

For a quick conversion, paste text into our Base64 encoder and decoder. Avoid pasting real secrets into any website, including ours; use local tools for those.

On Linux and macOS:

echo -n 'Hello, world!' | base64          # SGVsbG8sIHdvcmxkIQ==
echo 'SGVsbG8sIHdvcmxkIQ==' | base64 --decode

The -n matters: without it, echo adds a newline that changes the output. (On older macOS versions the decode flag is -D.) In PowerShell:

[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, world!'))
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIHdvcmxkIQ=='))

In most programming languages there is a standard library function: base64_encode() in PHP, the base64 module in Python, and btoa()/atob() in browsers (which only handle Latin-1 text directly, so encode Unicode to bytes first).

Key takeaways

Base64 encodes binary data as 64 safe text characters, 6 bits per character.
Output is about one-third larger than the input; = signs are padding.
It is used in email attachments, data URLs, Basic auth, JWTs, PEM files and DKIM records.
It is reversible by anyone: never treat Base64 as encryption.

Networking articles