Base64 Encoder / Decoder

Base64 is a binary-to-text encoding that represents any byte sequence using only 64 printable ASCII characters. This tool encodes text to Base64 or decodes a Base64 string back to its original UTF-8 text. It is UTF-8 safe, so non-ASCII characters like é, ñ, ü, and emoji survive the round-trip. The encoding is reversible, deterministic, and defined in RFC 4648.

Base64 is used everywhere in modern software, from inline images and fonts in CSS, to JSON Web Tokens, MIME email attachments, and SSH public key files. It is not encryption: anyone can decode it. Use it when you need to move binary data through a text-only channel, or when you want a compact, printable representation of bytes that you can paste into a URL, file, or form.

How to Use This Tool

1. Pick Encode or Decode from the dropdown.
2. Type or paste your text (or Base64) into the input area.
3. Click Convert to see the result.
4. Use Copy to copy the output to your clipboard.

The encoder maps each character of your input to its UTF-8 byte sequence, then groups those bytes into 6-bit chunks and writes out the matching Base64 character. The decoder reverses the process: it reads 4 Base64 characters at a time, recombines them into 3 bytes, and interprets those bytes as UTF-8. If the input contains characters outside the allowed Base64 alphabet, the decoder returns an error instead of producing garbage.

What Base64 Is

Base64 maps every 6 bits of input to one of 64 printable ASCII characters (A-Z, a-z, 0 to 9, +, /). Three input bytes become four output characters; the output is padded with = to a multiple of 4 characters. It is defined in RFC 4648. The 64-character alphabet was chosen so that the result is safe to transmit through systems that historically only handled 7-bit ASCII, teletype terminals, early email gateways, and HTTP headers that strip high bits.

The encoding is symmetric: encoding the same bytes always produces the same Base64 string, and decoding the same Base64 string always produces the same bytes. There is no secret key, no salt, and no randomization. This is what makes Base64 useful for encoding and what makes it useless for confidentiality.

Worked Examples

• Encode: Hello → SGVsbG8=
• Encode: Hello, World! → SGVsbG8sIFdvcmxkIQ==
• Decode: SGVsbG8= → Hello
• UTF-8 round-trip: résumé café → csOpc3Vtw6kgY2Fmw6k= → résumé café

Notice that the first example encodes Hello to SGVsbG8=, with a single = of padding because Hello is 5 bytes, not a multiple of 3. The second example, Hello, World!, is 13 bytes and therefore pads with two = characters. The UTF-8 example shows why a tool that handles bytes correctly matters: the accented characters are encoded as two-byte UTF-8 sequences first, then Base64-encoded, and the round-trip restores the original text exactly.

Where It Shows Up

• Data URLs, inline images and fonts in CSS using data:image/png;base64,...
• JWT tokens, JSON Web Tokens encode their header and payload in Base64URL
• Email attachments (MIME), Base64 transfers binary data over 7-bit SMTP channels
• Basic auth, HTTP Authorization: Basic base64(user:pass)
• XML / JSON embeds, packing binary blobs into text-only formats
• SSH keys, public keys are Base64-encoded when stored in .pub files

Data URLs are the most common reason a developer reaches for an encoder in the browser: you can embed an image directly in a CSS file or an HTML <img> tag without a separate file request. JWTs are the second most common: the header.payload.signature format uses Base64URL (not plain Base64) so that the token survives travel through URLs and HTTP headers without further escaping. Email attachments and Basic auth are older uses that predate the modern web, but both are still alive in legacy systems and tutorials.

Common Mistakes

• Treating Base64 as encryption. Base64 is encoding, anyone can decode it. Use a real cipher for secrets.
• Confusing Base64 with Base32 or Base58. They use different alphabets and are not interchangeable.
• Ignoring padding. Standard Base64 uses trailing = for alignment. Missing padding breaks strict decoders.
• Confusing Base64 with Base64URL. Base64URL uses - and _ instead of + and /, and typically omits padding.
• Encoding binary blobs without UTF-8 thinking. This tool handles text only. For binary data, use a hex or file-encoding tool.

The most dangerous mistake is the first one. Passwords, API keys, and tokens that are merely Base64-encoded are not protected, they are published in a slightly less obvious form. If you need confidentiality, you need a real cipher (AES, ChaCha20, RSA, etc.) and a real key management story. Base64 is a transport format, not a security boundary.

Frequently Asked Questions

What characters are valid in Base64?

The standard alphabet is A-Z, a-z, 0 to 9, +, /, and = for padding. The Base64URL variant uses - and _ instead. Any other character makes the input invalid and the decoder returns an error. Whitespace inside the input is generally tolerated by lenient decoders but is not part of the standard.

Is Base64 the same as encryption?

No. Base64 is a public, reversible encoding, it is not a secret. Anyone who sees a Base64 string can decode it. Use AES, RSA, or another cipher for confidentiality. Treating Base64 as "obscured" data is a common but serious security mistake.

Why does the output sometimes end with = or ==?

Base64 outputs in groups of 4 characters. If the input byte length is not a multiple of 3, the last group is padded with one or two = characters so the total length is always a multiple of 4. A single = means the input had 2 bytes left over; == means 1 byte left over.

Can I encode emoji and other Unicode?

Yes. This tool encodes text as UTF-8 first, then Base64, so emoji, accented letters, and CJK characters round-trip correctly. The plain btoa() function in browsers does not handle multi-byte UTF-8 by itself, which is why this tool uses the btoa(unescape(encodeURIComponent(t))) idiom to encode the UTF-8 byte sequence first.

What is the difference between Base64 and Base64URL?

Base64URL (RFC 4648 §5) replaces + with - and / with _, and usually drops padding. It is used in JWTs and URLs because those contexts cannot safely carry +, /, or = without additional escaping. The decoder logic is the same; only the alphabet and padding rules differ.

How long does the output get?

Base64 output is roughly 4/3 the size of the input bytes (about 33% larger). A 100-character text input produces ~136 characters of Base64. The expansion is fixed and predictable, which is why Base64 is sometimes used inefficiently where a smaller encoding (Base85, for example) would do.

Why does my decoded output look broken?

The most common cause is that the input was not Base64 to begin with, it was a URL-safe variant, a Base32 string, or a hex string. Another common cause is missing or extra padding. A third cause is that the original bytes were not UTF-8 (for example, they were UTF-16 or a binary blob) and the decoder is misinterpreting them. Re-encode with the matching tool and try again.

Is Base64 the same as uuencode?

No. uuencode is an older encoding used on Unix systems in the 1980s for transferring binary files over email. It uses a different alphabet, a different chunking scheme, and is now mostly historical. If you have a uuencoded file, you need a different decoder.

Can Base64 strings be shortened?

Not without changing the alphabet. If you are willing to drop readability, you can switch to Base85 (also called Ascii85) which encodes 4 bytes into 5 ASCII characters, about 25% overhead instead of 33%. Some short-form IDs (used in services like YouTube and Cloudflare) use Base58, which omits visually ambiguous characters like 0, O, I, and l to make IDs easier to copy by hand. Each variant has trade-offs; Base64 is the standard because it is the most widely supported.

Why is the output always divisible by 4?

The encoder always pads to a multiple of 4 because the decoder needs to know exactly where each 24-bit group ends. Without padding, the same sequence of bits could be split in different ways, producing different bytes. The = characters are not part of the data, they are just a length signal.

Does Base64 compress data?

No. Base64 actually expands data by about 33%. It is a transport encoding, not a compression algorithm. If you need to reduce size, run the data through gzip, Brotli, or zstd first, then Base64-encode the compressed output. Some storage formats (for example, certain database fields or JSON payloads) will be unhappy with raw binary bytes, so Base64 is the safe way to inline compressed data.

Why is UTF-8 handling tricky in JavaScript?

The browser's built-in btoa() function only accepts strings that contain code points in the range 0 to 255. That is enough for Latin text but breaks immediately for accented characters, emoji, or any non-ASCII input. The standard workaround is the btoa(unescape(encodeURIComponent(text))) idiom used in this tool: encodeURIComponent escapes the UTF-8 bytes as percent escapes, unescape turns those escapes into raw byte characters, and btoa then treats them as a binary string. The inverse, decodeURIComponent(escape(atob(b64))), reverses the chain. Both steps are needed because the conversion between UTF-8 and a binary string is not symmetric in any other way.

How Decoding Works Step by Step

To make the encoding concrete, here is the byte-by-byte walkthrough for the input Hello:

1. Take the ASCII bytes: H (0x48), e (0x65), l (0x6C), l (0x6C), o (0x6F), five bytes total.
2. Split into 6-bit groups across the whole bit stream: 010010 000110 010101 101100 011011 000110 111101. The last group has fewer than 6 bits, so we pad it with zeros.
3. Translate each 6-bit value through the alphabet: A=0, B=1, ..., Z=25, a=26, ..., z=51, 0=52, ..., 9=61, +=62, /=63.
4. The first six groups give S, G, V, s, b, G, 8. The trailing partial group becomes =.
5. The final output is SGVsbG8=.

The decoder does the same thing in reverse: it reads 4 characters, looks up the 6-bit value of each, concatenates the 24 bits, splits into 3 bytes, and continues. If the input contains characters outside the alphabet, or the number of characters is not a multiple of 4 (after removing padding), the decoder returns an error rather than producing garbage. This is also why the = characters are needed at the end: they tell the decoder exactly how many bytes the last group produced.

Binary Data and File Uploads

This tool is text-only: it expects that whatever you paste is a UTF-8 string, and it produces a UTF-8 string on decode. If you need to encode a binary file (an image, a PDF, a compiled binary), you should read the file as a Uint8Array of bytes on a platform that supports it, encode those raw bytes directly, and then treat the result as a sequence of ASCII characters. The browser's btoa() function does not accept Uint8Array directly, but the standard idiom is to convert each byte to a character first:

btoa(String.fromCharCode.apply(null, bytes))

For decoding binary, you build a Uint8Array from the codepoints of the decoded string. None of those steps are part of this tool, because the goal here is text-in / text-out. For files, reach for a dedicated file-base64 utility. Treating binary data as a UTF-8 string will silently corrupt anything that is not valid UTF-8, which is most binary data, so this tool refuses to do it for you.

Security and Privacy

Base64 has no security properties. It is not encryption, it is not hashing, and it offers no integrity checking. If you are tempted to "hide" a secret by Base64-encoding it, stop: anyone who sees the encoded string can decode it in a single step, and search engines, log files, and copy-paste buffers will happily store the un-obscured secret.

If you need real confidentiality, use a real cipher: AES-GCM for symmetric data, RSA-OAEP or X25519 for key exchange, and a trusted key management story (not a hard-coded key). If you need integrity, use a MAC (HMAC-SHA256, for example) or an authenticated cipher. If you need tamper-evidence, use a signature. None of these are Base64; Base64 is the layer you put on the outside so that the ciphertext, the signature, or the key can travel safely through text-only channels.

Treat Base64 as packaging, not protection. The same warning applies to "encoding" private keys as Base64 for storage, that is a presentation format, not a security measure, and the file should still be protected by file permissions, encryption, or a secrets manager. Logging tools, crash reporters, and analytics that accidentally capture Base64-encoded payloads will quietly leak the original data to anyone who reads the logs.

Performance and Size

For each 3 input bytes, Base64 produces 4 output characters. The 33% expansion is fixed and predictable. For very large inputs (megabytes), the encoding and decoding cost is dominated by the byte-to-character conversion, which in modern JavaScript engines runs at hundreds of megabytes per second. The clipboard operations for very large outputs may be slow or fail (most browsers cap clipboard writes at a few megabytes), so for large payloads prefer to download the result as a file or stream it through a server-side encoder.

If you are encoding data that will be stored in a JSON or YAML file, Base64 is a safe choice because it cannot break the surrounding syntax. If you are encoding data that will be embedded in a URL or HTTP header, switch to Base64URL to avoid the +, /, and = characters that have special meaning in those contexts. The choice of alphabet is the only difference between standard Base64 and Base64URL, the underlying bit packing is identical, so a good library will let you switch with a single flag.

References

• RFC 4648, The Base16, Base32, and Base64 Data Encodings. Defines the standard alphabet and padding.
• RFC 2045, Multipurpose Internet Mail Extensions (MIME). Specifies Base64 for email transfer.
• Joseph D. Touch, "Base-N Encodings", historical reference for the encoding family.

RFC 4648 is the canonical reference for any Base64 implementation. RFC 2045 is the older MIME standard that first standardized Base64 for email. Both documents are short, clear, and worth a read if you are implementing or auditing a Base64 codec.

Related Tools

• URL Encoder / Decoder, percent-encode strings for use in URLs.
• JWT Decoder, decode JWT header and payload (Base64URL).
• Hex Encoder, encode bytes as hexadecimal.