Base64 Encoder / Decoder

What Base64 actually encodes, and why it exists

Computers store everything as raw bytes, but many of the pipes data travels through — email bodies, JSON fields, URL query strings, HTML attributes — were built to carry printable text, not arbitrary binary, and can strip high-bit bytes or choke on reserved symbols. Base64 makes that irrelevant: it repackages any bytes into a string built only from 64 safe characters (A–Z, a–z, 0–9, +, /), so the result can sit inside a JSON string, a JWT, an <img> src="data:..." attribute, or an email attachment without anything downstream misreading it.

It's a transport encoding, not compression and not encryption — the output is always larger than the input, and anyone can decode it back with no key. Its only job is making binary data survive text-only channels intact.

Using this encoder / decoder

1. Text tab: choose Encode or Decode, then type or paste into either the Text box or the Base64 box — the other box fills in live. Encoding reads your input as UTF-8 bytes first, so Korean, Japanese, Chinese and emoji encode and decode losslessly, not just plain ASCII.
2. URL-safe checkbox: tick it before encoding for a URL, filename, or JWT segment. Decoding accepts either alphabet automatically, so you never need to untick it just to paste something in.
3. Image tab: drop or choose a file for a ready-to-use data: URI plus the raw Base64 payload. To reverse it, paste a Base64 string or data URI into the decode box, preview, then download the reconstructed file.

The mechanics: 6-bit groups and padding

Base64 works by regrouping bits, not bytes. Input bytes are 8 bits each, but the 64-symbol alphabet only needs 6 bits per character (2⁶ = 64). The encoder takes 3 input bytes (24 bits) at a time and re-slices those 24 bits into four 6-bit chunks, each mapped to one output character — a 3-bytes-in → 4-characters-out ratio, which is exactly why output is always about 33% larger than the source.

When the input length isn't a multiple of 3, the last group is short. The encoder pads the missing bits with zeros and appends = characters so the decoder knows how many trailing bits were real data. One leftover byte yields ==; two leftover bytes yield a single =; a clean multiple of 3 needs no padding.

Worked examples

How much bigger does Base64 make things?

Every 3 input bytes become 4 output characters, so output size is predictable — useful when deciding whether to embed an image as a data URI instead of linking to it as a file.

The overhead converges to exactly 4/3 (≈33.3%) for larger inputs; small inputs look worse only because of the fixed padding on the last group.

Standard vs. URL-safe Base64

Two of the 64 alphabet characters — + and / — are meaningful symbols inside URLs and file paths, and = padding is reserved in query strings. RFC 4648 §5 defines a URL-safe variant that swaps those two characters and drops the padding, so the string needs no escaping inside a URL, filename, or JWT segment:

For example, the 3 bytes 0x01 0x0f 0xfe encode to AQ/+ in standard Base64 but AQ_- in URL-safe form — same data, characters swapped, padding dropped. Tick the URL-safe box before encoding if the output is headed into a URL, a filename, or a JWT; leave it off for JSON payloads or anything else that doesn't care about those symbols.

Common mistakes

• Assuming Base64 is encryption. It has no key or secret — anyone can decode it instantly. Never use it to "hide" passwords or personal data; it only changes the character set, not the confidentiality.
• Encoding non-Latin1 text with a naive btoa() call. Plain btoa() only understands code points 0–255, so Korean, emoji, or most CJK text throws or corrupts. Convert to UTF-8 bytes first, which this tool does automatically.
• Mixing the two alphabets by hand. Swapping +// for -/_ without also handling the padding causes silent decode failures in stricter parsers.
• Forgetting the data URI prefix matters. An <img> tag or CSS background-image needs the full data:image/png;base64,... string, not just the raw payload — this tool gives you both, separately.
• Base64-encoding large files "to save space." It does the opposite, inflating size by roughly a third — use it for portability, not storage efficiency.

What this tool doesn't do

This is encoding, not compression or encryption, and it doesn't validate that decoded image bytes form a well-formed file — if you paste corrupted or truncated Base64, the browser's image preview may simply fail to render. For genuinely sensitive data, encrypt first and Base64-encode the ciphertext only if you need it in a text-safe channel.