Base64 Encoding Explained

How Base64 works

Base64 takes binary data, splits it into chunks of 3 bytes (24 bits), and re-splits those bits into four groups of 6 bits. Each 6-bit group maps to one of 64 characters: A–Z, a–z, 0–9, plus "+" and "/". That is where the name comes from — a base-64 alphabet of 64 symbols.

Because 3 bytes always become 4 characters, Base64 output is about 33% larger than the input. If the input length is not a multiple of 3, padding characters ("=") are added at the end so the decoder knows how many bytes to reconstruct. Decoding reverses the process exactly, so Base64 is lossless — you always get back the original bytes.

Hello  ->  SGVsbG8=
Hello! ->  SGVsbG8h
Binary image data -> iVBORw0KGgoAAAANSUhE...

Where you meet Base64 every day

Email attachments are the classic use case: email was built for text, so attachments are Base64-encoded into the message body. Data URLs in web pages work the same way — a small image can be embedded directly in HTML or CSS as data:image/png;base64,..., which saves a network request. JWT authentication tokens also carry a Base64-encoded header and payload, and many APIs accept Base64 when you need to send a file inside a JSON body.

You will also see Base64 in basic HTTP authentication (username:password encoded in the Authorization header), in configuration files that embed certificates, and in developer tools that need to display binary data as copyable text.

Base64 is not encryption

This is the most important thing to understand about Base64: it provides zero security. Encoding is not encryption — there is no key, and anyone who recognizes the format can decode it instantly. Never use Base64 to "hide" a password, a secret or personal data. If something must stay secret, encrypt it properly first, and only then encode the encrypted bytes for transport if needed.

A useful mental model: Base64 is a shipping box, not a safe. It protects data from being mangled by text-only systems, but it does not protect it from being read.

Base64 in URLs: the URL-safe variant

Standard Base64 uses "+" and "/", which have special meanings in URLs, and "=" padding can also cause trouble. The URL-safe variant replaces "+" with "-" and "/" with "_", and often drops the padding. Many modern APIs and token formats use this variant. If you are putting encoded data into a query string or a path segment, use URL-safe Base64 or percent-encode the standard output.

When to use Base64 — and when not to

Use Base64 when a text-only channel must carry binary data: embedding a small image in CSS, sending a file inside JSON, or storing a token as a string. Avoid it for large files, because the 33% size overhead adds up quickly — a 3 MB image becomes 4 MB of text. For large files, upload the binary directly instead of encoding it.

Also avoid Base64 for data that humans need to read or edit. It is deliberately unreadable, so it makes debugging harder and diffs useless. Encode at the boundary where the data enters the text channel, and decode as soon as it leaves.

• Do use it for small images in data URLs, tokens, and files inside JSON.
• Do not use it as a way to hide secrets — it is not encryption.
• Do not use it for large files — the 33% overhead is wasteful.
• Prefer URL-safe Base64 inside URLs and query strings.

Encoding a file step by step

To encode a file, open a Base64 file converter and drop the file in. The tool reads the bytes, encodes them, and gives you a text string you can copy. For a small image, you can then paste that string straight into a stylesheet as a data URL — data:image/png;base64, followed by the encoded text — and the browser will render the image without a separate download.

To go the other way, paste a Base64 string into the converter and download the decoded file. Check the output size: if the decoded file is much smaller than the encoded text suggested, something may have been truncated — a missing padding character is the usual cause. For very large files, prefer a direct upload; encoding a 50 MB video would produce about 67 MB of text, which most text fields will reject.

Base64 vs hex: a quick comparison

Hex is the other common way to write binary as text: every byte becomes two hexadecimal characters (0-9, a-f). Hex is easier to read and compare by eye — you can spot a changed byte at a glance — but it doubles the size of the data, while Base64 only adds a third. That is why hashes are usually shown in hex (readability matters more than size for a 32-byte fingerprint) and files are sent in Base64 (size matters more).

Neither format hides anything: both are plain encodings, decodable by anyone. Choose hex when humans need to read or compare the output, and Base64 when the data must travel through a text channel as compactly as possible.