Base64 エンコード/デコード

What Base64 actually is

Base64 is a way to represent binary data — bytes — using only 64 printable ASCII characters. Those characters are the 26 uppercase letters, the 26 lowercase letters, the ten digits, plus + and /, with = reserved as padding. The point is not to hide or protect anything; it is to make arbitrary bytes survive travel through channels that were built for text and that would otherwise mangle, strip, or choke on raw binary. Email bodies, JSON strings, HTML attributes, HTTP headers, and URLs all expect text. Base64 lets you stuff a PNG, a PDF, or an encryption key into any of them safely.

Encoding, not encryption

This is the single most important thing to understand: Base64 is encoding, not encryption. There is no key and no secret. Anyone who sees a Base64 string can decode it back to the original bytes in a fraction of a second — this very tool does exactly that with the Decode button. Treating Base64 as a security measure is a classic and dangerous mistake. If you Base64-encode a password and put it in a config file, you have hidden nothing; you have merely made it slightly less obvious to a casual reader. Use real encryption (AES, for example) when you need confidentiality, and reach for Base64 only when you need to transport data, not protect it.

How the algorithm works

Base64 works on groups of three bytes. Three bytes are 24 bits. Those 24 bits get re-sliced into four groups of 6 bits, and each 6-bit value (0–63) is mapped to one character from the alphabet. So every 3 input bytes become 4 output characters. When the input length is not a multiple of three, the encoder pads the final group with = signs so the output is always a multiple of four characters.

A worked example

Take the three characters Man. Their ASCII byte values are 77, 97, 110, which in binary are 01001101 01100001 01101110. Concatenate those 24 bits and re-split into six-bit chunks: 010011 010110 000101 101110. As decimal those are 19, 22, 5, 46, which map to the characters T, W, F, u. So Man encodes to TWFu. Now encode just M (one byte): you get two meaningful characters plus two padding signs, TQ==. Encode Ma (two bytes) and you get TWE= — one padding sign. The padding count tells the decoder how many real bytes the final group held.

The 33% size overhead

Because every 3 bytes become 4 characters, Base64 output is always about one-third larger than the input — a 3:4 ratio is a 33% increase, before counting any line breaks some formats add. A 1 MB image becomes roughly 1.33 MB of text. This matters in practice. Inlining images as Base64 data: URIs in CSS or HTML avoids extra HTTP requests, but it inflates the page payload and the bytes cannot be cached separately from the document. For small icons the trade is often worth it; for large media it usually is not.

Where Base64 shows up

• Email attachments. The MIME standard uses Base64 to embed binary files in messages that are fundamentally text.
• Data URIs. data:image/png;base64,iVBORw0KG... embeds an image directly in markup or a stylesheet.
• JSON and APIs. JSON has no binary type, so a file or a hash is commonly carried as a Base64 string.
• JWTs and tokens. JSON Web Tokens are three Base64url-encoded segments joined by dots — encoded, not encrypted, which is why their payload is readable.
• Basic HTTP auth. The Authorization header sends user:password as Base64 — again, encoded only, which is exactly why that scheme requires HTTPS.

Standard vs URL-safe

The standard alphabet uses + and /, but both characters have special meaning inside URLs (+ can mean a space, / is a path separator) and = is reserved too. The URL-safe variant — which the checkbox in this tool enables — swaps + for - and / for _, and drops the trailing = padding. When decoding URL-safe input, the tool reverses the swap and re-adds padding until the length is a multiple of four. Use URL-safe encoding whenever the result will live in a query string, a path segment, a cookie value, or a filename.

Common mistakes and tips

• Encoding non-ASCII text without UTF-8. This tool encodes the bytes of the UTF-8 representation, so emoji and accented characters round-trip correctly. Decoders that assume Latin-1 will corrupt them.
• Forgetting padding. Stripping = is fine for URL-safe transport, but the decoder must re-add it. Pasting unpadded standard Base64 into a strict decoder fails.
• Mixing the two alphabets. A string with - or _ needs URL-safe decoding; one with + or / needs the standard mode. Choosing the wrong one yields garbage or an error.
• Assuming it compresses. Base64 never makes data smaller — it always grows. If size matters, compress first, then encode.

Everything here runs locally in your browser using the built-in btoa/atob functions plus UTF-8 text encoding, so the data you paste is never uploaded anywhere.