Base64 Encoder/Decoder

Type in either box — plain text or Base64 — and the other updates live. Handles Unicode text (accents, emoji, non-Latin scripts) correctly, not just plain ASCII.

How Base64 Encoder/Decoder Works

Base64 is a way of representing binary data (or any byte sequence) using only 64 printable ASCII characters -- A-Z, a-z, 0-9, +, and /. It exists because many older systems (email, some URLs, JSON/XML payloads) can't safely carry arbitrary bytes, so Base64 re-packages those bytes into plain text that survives the trip unchanged.

Formula & Method

The encoder first converts your text to UTF-8 bytes, then groups those bytes 3 at a time (24 bits) and re-splits each group into four 6-bit chunks, each mapped to one of the 64 alphabet characters. If the final group has fewer than 3 bytes, the output is padded with = so the length is always a multiple of 4. The URL-safe variant swaps +- and /_ (both of which have special meaning in URLs and file paths) and drops the = padding entirely, since padding can be reconstructed from the string length when decoding.

Worked Example

Encoding Hello, World! (13 bytes) produces SGVsbG8sIFdvcmxkIQ== (20 characters, standard alphabet) or SGVsbG8sIFdvcmxkIQ (18 characters, URL-safe, no padding). Either decodes back to the exact original bytes.

Frequently Asked Questions

Why is the Base64 output always longer than the original?
Every 3 bytes of input becomes 4 Base64 characters, so the output is asymptotically about 33% larger than the input. Very short inputs can show a bigger percentage increase than that, because padding rounds the output up to the next multiple of 4 characters regardless of how few bytes are left over.
Is Base64 encryption or a way to hide data?
No -- Base64 is a reversible encoding, not encryption. Anyone can decode it back to the original text instantly with no key or password; it provides zero confidentiality and should never be used as a substitute for actual encryption.
When should I use the URL-safe variant?
Use it whenever the encoded string will appear inside a URL, a file name, or a query parameter -- the standard alphabet's + and / characters can be misinterpreted there (as a space or a path separator), while the URL-safe alphabet avoids both.
Why does decoding sometimes fail or show a warning?
Decoding fails outright if the input contains characters outside the Base64 alphabet or has invalid padding for its length. It succeeds but shows a warning if the decoded bytes aren't valid UTF-8 text -- that usually means the Base64 actually encodes binary data (an image, a file, etc.), not text, so the best-effort text rendering won't be meaningful.
Base64 Characters