Base64 Encode / Decode

What is Base64?#

Base64 is a way to write arbitrary bytes using only 64 printable ASCII characters (A-Z, a-z, 0-9, +, /, with = for padding). It exists because huge swaths of the computing world were designed for text — email bodies, JSON fields, HTTP headers, data-URI prefixes — and they choke on raw bytes, especially bytes with the high bit set or control codes embedded in them. Base64 is the lingua franca you reach for when you need binary-shaped data to survive a text-only channel.

Every three input bytes (24 bits) become four base64 characters (each encoding 6 bits). That is why base64 output is always a multiple of four characters long, and why it is roughly 33% larger than the original bytes — the redundancy is the price of printability. When the input length is not a multiple of three, one or two = padding characters appear at the end.

This page encodes and decodes base64 safely with UTF-8. A trap people hit constantly: passing a string straight to btoa() throws InvalidCharacterError the moment it contains a non-ASCII character (é, 中文, an emoji). The fix is to encode the text to UTF-8 bytes first, then base64 — which is exactly what this tool does, so café round-trips correctly instead of throwing.

How to use it#

1. Pick the direction with the Encode / Decode toggle at the top-left of the toolbar.
2. Type or paste into the Input pane on the left.
   • In Encode mode the input is treated as UTF-8 text.
   • In Decode mode the input should be a base64 string. Whitespace is tolerated.
3. Tick URL-safe if you need the base64url alphabet (- and _ instead of + and /, padding stripped). This is what JWTs and many signed-URL schemes expect.
4. The result appears live in the Output pane on the right. Click Copy to grab it.
5. Use Sample to drop in a demonstration pair, and Clear to reset both panes.

Key features#

• UTF-8 safe in both directions. Encoding runs the text through TextEncoder first, so multibyte characters never blow up; decoding runs the bytes through TextDecoder so the original text is restored exactly.
• Standard and URL-safe alphabets. One checkbox switches between classic base64 (+/=) and base64url (-_ with no padding), with correct re-padding on decode.
• Pure client-side. The conversion runs in your browser only — there is no backend and no network request. Pasting a sensitive token here does not send it anywhere.
• Live status line. The bar below the panes reports encode/decode errors (for example, a %-shaped or truncated input) instead of silently producing garbage.

Worked example#

With Encode and standard (not URL-safe) mode, the ASCII text Hello, World! becomes:

SGVsbG8sIFdvcmxkIQ==

The two trailing = show that the 13-byte input was not a multiple of three — that is expected, not a mistake.

The UTF-8 handling matters as soon as you leave ASCII. Encoding café (where é is two UTF-8 bytes, c3 a9) gives:

Y2Fmw6k=

If you had called btoa("café") directly in a console, it would have thrown. This tool does not, because it encodes UTF-8 bytes first.

URL-safe mode rewrites the alphabet so the output never carries characters a URL would misread: + becomes -, / becomes _, and the trailing = padding is removed (re-added automatically on decode). Take the standard output from above, SGVsbG8sIFdvcmxkIQ== — in URL-safe mode the two padding = are stripped, giving SGVsbG8sIFdvcmxkIQ. The +// → -/_ swap only changes anything when those characters actually appear in the output, which tends to happen with binary payloads such as hash digests or random tokens — exactly the kind of data you slot into a URL path or query parameter without further escaping.

FAQ#

My decoded text shows up as mojibake. What happened?#

Almost always, the base64 you decoded was the encoding of bytes in some other character set (often Latin-1 or Windows-1252), not UTF-8. This tool decodes the bytes as UTF-8, so a Latin-1-encoded é (0xe9, a lone byte) is not valid UTF-8 and shows up wrong. Find out how the other end encoded the original text, or re-encode it as UTF-8 first.

Standard base64 or base64url — which do I want?#

Standard (+/=) is the default for anything that is not going into a URL: email attachments, data: URIs, JSON fields carrying binary. Switch on URL-safe when the output will sit in a URL path, query string, or a JWT segment, where +, /, and = either break parsing or get mangled by transport. Decoding either form is accepted automatically.

Why is the encoded output longer than my input?#

That is inherent, not a bug. Base64 packs 6 bits per character instead of 8, so the output is about 4/3 the size of the input — roughly a 33% overhead. For very small inputs it can look even larger relative to the original, because the fixed structure dominates.

Can this decrypt or crack a base64 string?#

No — base64 is an encoding, not encryption. It is fully reversible by design and carries no key. Anyone with the string can decode it. If you actually need secrecy, encrypt first (for example with an authenticated-encryption scheme) and then base64-encode the ciphertext for transport.