Base64 encoder and decoder

What is Base64?

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

Base64 is encoding, not encryption. Anyone who sees the encoded string can decode it. Use it when you need to send 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 get the file back.
• Inspecting an encoded payload. Webhook signatures, S3 ETags, JWT pieces, and other small binary values are often Base64.
• Preparing test fixtures. Putting a small binary file inside a JSON test fixture is cleaner than reading it from a separate file.

How Base64 works

Take three input bytes (24 bits). Cut them into four 6-bit groups. Look up each group in the 64-character alphabet. That is the output. If the input length is not a multiple of three, pad the last group with zero bits and add = 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) uses - and _ instead, so the string is safe in a URL or file name 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+agA==. A plain btoa() call in the browser would throw, because btoa only takes Latin-1; this page uses TextEncoder to turn the text into UTF-8 bytes first.

Common mistakes

• Treating Base64 as secret. Encoding a password as Base64 is no protection. Anyone with the encoded string can decode it in one line of code.
• UTF-8 against Latin-1. The browser's built-in btoa(s) only accepts Latin-1; passing it Unicode text throws. Always turn text into UTF-8 bytes first (TextEncoder) before Base64 encoding.
• Mixing standard and URL-safe. A decoder set to standard Base64 rejects a URL-safe string, because - and _ are not in its alphabet. Pick one and use it on both sides.
• Padding mismatch. Some encoders drop the = padding, some do not. Strict decoders reject input without padding. If decoding fails, add = until the length is a multiple of four.
• Size growth. Base64 makes the data about 33% bigger. For large payloads (images, files), gzip the original before encoding to win some of that back.

FAQ

Is Base64 encryption?

No. Base64 is an encoding, not encryption. Anyone who sees the encoded string can reverse it; use it for transport, not for secrecy.

What is the difference between standard and URL-safe Base64?

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

Why is my decoded text garbled?

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

Does Base64 make the data bigger?

Yes. Base64 adds about 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 an encoder that works on bytes.