Base64 Encoder / Decoder

Base64 Encoder and Decoder: Convert Data to Text

Base64 turns binary data into printable text. It appears in data URLs, email attachments, JSON payloads, and API requests. This tool encodes text to Base64 and decodes Base64 back into readable text directly in your browser.

How Base64 works

Base64 uses 64 characters to represent binary bytes: A–Z, a–z, 0–9, plus + and /. The = at the end is padding. Every three bytes become four Base64 characters, so the encoded result is about 33 percent larger than the original. Because the alphabet contains only printable, non-control characters, Base64 data travels safely through emails, URLs and JSON.

Examples:

• Man → TWFu (the classic example: 3 bytes, 24 bits, split into four 6-bit groups)
• a → YQ== (one byte plus two padding characters)
• Hello World → SGVsbG8gV29ybGQ=

Step by step: where TWFu comes from

The letters M, a and n have the ASCII values 77, 97 and 110, that is the bytes 01001101 01100001 01101110. These 24 bits are split from the left into four groups of six bits: 010011, 010110, 000101, 101110. As decimals those are 19, 22, 5 and 46. In the Base64 alphabet these map to T, W, F and u, giving TWFu.

Why the output is about 33 percent larger

The reason lies in the mathematics of the method. A byte holds 8 bits, but a Base64 character carries only log2(64) = 6 bits. So three bytes (24 bits) become four characters (4 × 6 = 24 bits). Every three-byte block adds four characters, a ratio of 4 to 3, or about 33 percent more than the original. For leftover lengths the output is padded with =, for example a becomes YQ==, so the length stays divisible by four.

Common decoding pitfalls

Even though Base64 looks simple, there are traps. If the input contains characters outside the alphabet (for example a stray space or an umlaut in the wrong context), or the length is not properly divisible by four without correct padding, decoding usually stops. The browser reports an invalid input, and this tool catches that and shows a clear error message. Always copy strings completely and without hidden line breaks.

Where Base64 is used

• Email attachments (MIME) emails can only transport text, so images, PDFs and other files are embedded as Base64
• Data URLs in the web embed images directly in HTML or CSS
• API authentication basic auth encodes username and password as Base64 (not encrypted, so use HTTPS only)
• JSON Web Tokens (JWT) the three parts are base64url-encoded JSON objects
• JSON payloads pack binary data into a string

Encoding vs. decoding

• Encoding turns plain text into Base64. For example Hallo Welt becomes SGFsbG8gV2VsdA==.
• Decoding reverses it. From SGFsbG8gV2VsdA== you get Hallo Welt back.

Base64URL and the JWT connection

Standard Base64 includes the characters + and /, which are awkward in URLs and file names. The Base64URL variant replaces them with - and _ and usually omits the = padding. This form is used in the three parts of a JSON Web Token (JWT), which you can inspect with our JWT decoder.

Encoding is not encryption

Base64 is an encoding format, not a security method. Anyone can decode a Base64 string in a click. Use real encryption such as AES or HTTPS when data must remain confidential.

What about umlauts and emoji?

The alphabet only covers Latin basic characters. Non-Latin input such as umlauts, emoji or other Unicode characters must first be encoded to UTF-8 bytes, which is exactly what the browser's standard functions do for plain text. The resulting Base64 then represents those UTF-8 bytes, which is why the same text can look different depending on the underlying encoding. If a string is not Latin-compatible, encoding can fail, and this tool shows that as a clear error.

Frequently asked questions