Base64 Encoder & Decoder

What Is Base64 Encoding?

Base64 is a binary-to-text encoding scheme: it takes arbitrary binary data (raw bytes) and represents it using only 64 printable ASCII characters — uppercase and lowercase letters, digits, and two symbols (typically + and /), with = used as padding at the end. It exists because many older systems and protocols (email, some text-based network protocols, certain markup and config formats) were designed to safely carry plain text but can corrupt or reject raw binary bytes — Base64 sidesteps that problem entirely by re-expressing binary data as ordinary text.

Base64 is not encryption, and it is not a security mechanism. This point trips up a lot of people, so it's worth stating plainly: encoding is a reversible, publicly documented transformation with no secret key involved. Anyone — or any tool, including this one — can decode a Base64 string back to its original content in a single step. If you need to keep data confidential, you need actual encryption (such as AES or TLS), not Base64. Base64's job is compatibility and safe transport, not secrecy.

Common Use Cases

• Data URIs: embedding small images, fonts, or icons directly inside CSS or HTML (e.g. data:image/png;base64,iVBORw0KGgo...) instead of a separate file request.
• Email attachments (MIME): email was originally a text-only protocol, so binary attachments like images and documents are Base64-encoded before being embedded in a message body.
• Binary data inside JSON or XML: both formats are text-based and can't natively hold raw binary bytes, so APIs often Base64-encode binary fields (file uploads, cryptographic signatures, thumbnails).
• HTTP Basic Authentication: the Authorization: Basic header carries a Base64-encoded username:password string (again — encoded, not encrypted, which is why Basic Auth requires HTTPS to be safe).
• URL-safe data transport: tokens, session identifiers, and JWTs often use a URL-safe variant of Base64 so the encoded value can appear directly in a URL or query string.

The Standard: RFC 4648

This tool implements standard Base64 as defined in RFC 4648, the IETF specification that also defines the URL-safe and Base32 variants. Standard Base64 groups input bytes into 3-byte chunks and maps each chunk to 4 output characters drawn from the alphabet A–Z, a–z, 0–9, +, and /, padding the final group with = characters when the input length isn't an exact multiple of 3 bytes. Text input is first converted to UTF-8 bytes, which is what makes multi-byte characters like emoji and accented or non-Latin letters encode and decode correctly.

Step-by-Step: How Encoding Works Under the Hood

It helps to see the mechanics once, even though the tool above does all of this instantly. Take the three-character string "Hi!":

1. Convert each character to its byte value: H = 72, i = 105, ! = 33. In binary (8 bits each), that's 01001000 01101001 00100001.
2. Because a 3-byte input maps cleanly onto Base64's 4-character output, regroup those 24 bits into four 6-bit chunks: 010010 000110 100100 100001.
3. Each 6-bit chunk is a number from 0–63, which indexes directly into the Base64 alphabet (A–Z = 0–25, a–z = 26–51, 0–9 = 52–61, + = 62, / = 63). The four chunks above are 18, 6, 36, 33 — which map to S, G, k, h.
4. Result: "Hi!" encodes to SGkh. Since 3 input bytes divided evenly into 4 output characters with nothing left over, no = padding is needed here — padding only appears when the final group has 1 or 2 leftover input bytes instead of 3.

Decoding just runs this process in reverse: look up each character's 6-bit value, concatenate them back into a stream of bits, and regroup that stream into 8-bit bytes to recover the original text. This tool does exactly that using the browser's built-in TextEncoder/TextDecoder and btoa/atob APIs, so the math above runs natively rather than in a slow, hand-rolled loop.

Base64 vs. Related Encodings

Base64 is one of several ways to represent binary or special data as plain text, and it's easy to conflate it with the others — here's how the common ones actually differ:

Base64 is the most space-efficient of the plain-text encodings above, which is why it's the default choice for embedding binary data (images, files, tokens) inside text formats — but note that it's the only row in this table without any confidentiality guarantee at all, encryption included by definition, the others by design intent.

Example Reference Table

Paste any of the plain-text values above into the tool to confirm the Base64 output matches, or paste a Base64 value to confirm it decodes back to the original text.

Troubleshooting & Practical Tips

Why Decoding Sometimes Fails

Standard Base64 only accepts a very specific set of characters, so decoding fails whenever the input strays outside it. The usual culprits:

• Stray whitespace or line breaks: copying from an email client or PDF can introduce invisible line-wrap characters in the middle of the string.
• Missing padding: valid standard Base64 length is always a multiple of 4 characters; if a system stripped the trailing = padding, decoding can fail or silently misbehave.
• The URL-safe variant: if the string uses - and _ instead of + and /, it's URL-safe Base64 (per RFC 4648 §5), not standard Base64 — swap the characters back before decoding here.
• Truncated copy-paste: a partially copied string will produce garbled or failed output because every group of 4 characters must be complete.

A Reminder on Security

Because decoding requires no key or password, never rely on Base64 to hide sensitive information such as passwords, API keys, or personal data in a URL, config file, or source code — treat anything Base64-encoded as fully readable by anyone who has it.

Frequently Asked Questions