Base64 Converter

How Base64 encoding works.

Base64 takes every three bytes of input and encodes them as four ASCII characters. The input is broken into 6-bit groups, and each group maps to one of 64 characters: A“Z, a“z, 0“9, +, and /. If the input length isn't a multiple of three, padding characters (=) fill the gap. This is why Base64 strings always end with =, ==, or nothing at all.

For example, the word "Hello" is five bytes. Base64 processes the first three bytes ("Hel") into "SGVs", then the remaining two bytes ("lo") plus a padding byte into "bG8=", giving you "SGVsbG8=" — which decodes back to "Hello". The overhead is roughly 33%, so a 1 KB string becomes about 1.33 KB when encoded.

When to use Base64.

Base64 is used whenever binary data needs to travel over a text-only channel. Email attachments (MIME/SMTP), data URIs in HTML and CSS, JWT tokens, Basic HTTP authentication headers, and embedding images in JSON all use Base64 to represent binary data as text. It's also common in config files where you need to store a certificate, key, or binary blob as a string.

In web development, data URIs use Base64 to inline small images directly in HTML or CSS: data:image/png;base64,iVBOR.... This avoids an extra HTTP request but increases the file size by about 33%. For images larger than a few KB, linking to an external file is usually faster.

Base64 vs encryption.

Base64 is encoding, not encryption. It uses a fixed, publicly known mapping — anyone can decode a Base64 string without a key. If you need to protect data, combine Base64 with proper encryption (AES, RSA, etc.) or use HTTPS for data in transit. Base64 is also not compression — encoded output is always larger than the input.

Common mistakes include treating Base64 as "scrambled" text, using it to hide passwords or secrets, and forgetting that the decoded output is UTF-8 text (not raw bytes). Always remember: if you can see the encoded string, anyone else can decode it too.

Base64 variants and URL-safe encoding.

The standard Base64 alphabet uses + and / as the last two characters, which can cause issues in URLs and filenames. URL-safe Base64 replaces these with - and _ respectively. This tool uses standard Base64 by default, but many web frameworks and libraries (like JWT) use the URL-safe variant. If you're working with JWTs or embedding encoded data in URLs, make sure you're using the correct variant.

Another variant is Base64url, which omits padding characters (=). This is common in JWTs and other token formats where padding would add unnecessary length. When decoding, this tool accepts both padded and unpadded input. When encoding, it produces standard padded output. If you need unpadded output for a specific API, simply remove the trailing = characters manually.

For binary data that needs to be transmitted over text channels — like embedding certificates in PEM files or encoding image data in JSON responses — Base64 remains the industry standard. While it adds 33% overhead, it ensures binary data survives passage through systems that only handle ASCII text safely.