Base64 encoder and decoder

What is Base64?

Base64 is a way to represent arbitrary binary data as plain ASCII text. It maps every three bytes of input to four characters drawn from a 64-character alphabet (A-Z, a-z, 0-9, plus two extras). The result is safe to drop into JSON, XML, URLs, email bodies, HTTP headers, or anywhere else where the transport assumes printable text.

Base64 is encoding, not encryption. Anyone who sees the encoded string can decode it. Use it when you need to ship binary through a text-only channel, not when you need secrecy.

When to use this tool

• Decoding an HTTP Authorization: Basic header.Basic auth is just base64(user + ":" + password); decoding shows you whether the client is sending what you expect.
• Reading a Data URI.data:image/png;base64,iVBORw0K... embeds raw bytes after the comma. Decode it to recover the underlying file.
• Inspecting an encoded payload.Webhook signatures, S3 ETags, JWT pieces, and other small binary blobs are often Base64.
• Preparing test fixtures.Embedding a small binary file inside a JSON test fixture is cleaner than reading from a separate file.

How Base64 works under the hood

Take three input bytes (24 bits). Slice them into four 6-bit groups. Look each group up in the 64-character alphabet. That's the output. If the input length isn't a multiple of three, pad the last group with zero bits and append = characters so the output length stays a multiple of four.

The standard alphabet (RFC 4648 section 4) uses + and / as the two extras. URL-safe Base64 (section 5) swaps those for - and _ respectively, so the string is safe in a URL or filename without percent-encoding. Most URL-safe variants also drop the trailing = padding since both sides know to add it back.

Worked examples

• "Tenali Ramakrishna"encodes to VGVuYWxpIFJhbWFrcmlzaG5h. No padding because the input length (18 bytes) is divisible by three.
• "Go"encodes to R28=. Two input bytes need one = of padding.
• "G"encodes to Rw==. One input byte needs two = of padding.
• The emoji "🚀"is a four-byte UTF-8 sequence (F0 9F 9A 80), which encodes to 8J+aoA==. A naive btoa() call in the browser would throw because btoa only takes Latin-1; the encoder on this page uses TextEncoder to convert to UTF-8 bytes first.

Common pitfalls

• Treating Base64 as secret.Encoding a password as Base64 is not protection. Anyone with the encoded string can decode it in one line of code.
• UTF-8 vs Latin-1.The browser's built-in btoa(s) only accepts Latin-1; passing it Unicode text throws. Always encode to UTF-8 bytes first (TextEncoder) before Base64-encoding.
• Mixing standard and URL-safe.A decoder set to standard Base64 will reject a URL-safe string because - and _ aren't in its alphabet. Pick one and stick with it across the wire.
• Padding mismatch.Some encoders strip = padding, some don't. Strict decoders reject unpadded input. If decoding fails, try adding = until the string length is a multiple of four.
• Size growth.Base64 grows the data by about 33%. For large payloads (images, files), gzip the original before encoding to claw some of that back.

FAQ

Is Base64 encryption?

No. Base64 is an encoding, not encryption. It is fully reversible by anyone who sees the encoded string; use it for transport, not for secrecy.

What's the difference between standard and URL-safe Base64?

URL-safe Base64 (RFC 4648 section 5) replaces + with -, / with _, and usually drops trailing = padding so the string is safe in URLs and filenames.

Why is my decoded text garbled?

Most likely the input was encoded with a different character set or used the URL-safe alphabet. Toggle "URL-safe" and try again, or check the source charset.

Does Base64 expand the data?

Yes. Base64 increases size by roughly 33% (every 3 input bytes become 4 output characters) plus padding.

Can I Base64-encode binary files here?

This page handles text only. Files (images, PDFs) need a binary-safe encoder; we will add file-mode in a follow-up.