Why does encoding text make it about a third bigger?

Base64 turns every 3 bytes into 4 printable ASCII characters, so the output is always about 33% larger than the input. That overhead is the cost of moving binary safely through text-only channels — it never shrinks data, so use a real compressor if size is the goal.

Can it handle emoji and Korean, or will it break like btoa()?

It encodes through UTF-8 first, so 한글 and 😀 round-trip exactly. The browser's built-in btoa() throws an error on any character above code point 255, which is the usual reason a hand-rolled Base64 snippet breaks the moment someone pastes an emoji.

What's the difference between standard and URL-safe Base64?

Standard uses + and /, which clash with URLs and filenames; URL-safe swaps them for - and _ and drops the trailing = padding. JWTs use the URL-safe (base64url) variant, and the decoder here accepts either alphabet automatically.

Is Base64 a way to hide or protect data?

No — it's reversible encoding, not encryption. Anyone can decode a Base64 string back to the original in one step, so never treat it as secure. Its only job is making binary safe to carry as text.

Why does my decoded output look like garbled characters?

Usually the original bytes weren't UTF-8 text — for example a raw image or a different encoding — so they don't map to readable characters. A genuine text payload decodes back intact; input that isn't valid Base64 shows an error instead.

Base64 Encode / Decode

Encode and decode text to Base64 — Unicode-safe, with a URL-safe option.

URL-safe

InputOutput

Converted locally — your text never leaves this browser.

What is Base64 Encode / Decode?

Base64 Encode / Decode converts text to Base64 and back as you type, with full Unicode support so characters like 한글 and emoji round-trip via UTF-8. Decoding accepts both the standard and URL-safe alphabets automatically, and a URL-safe toggle emits - and _ without padding. A free base64 encoder and decoder that runs in your browser.

Key features

Live encode and decode as you type
Unicode-safe: emoji and multi-byte text via UTF-8
URL-safe alphabet toggle without = padding
Decoder accepts standard and URL-safe input, ignoring whitespace
Swap button feeds the output back the other way

Base64 Encode & Decode — Unicode & URL-safe

Base64 represents arbitrary bytes using just 64 printable ASCII characters — A–Z, a–z, 0–9, and two symbols. It exists because many systems were built to move text, not raw binary: email bodies (MIME), JSON string fields, URLs, and inline data: attributes in HTML all expect characters, not arbitrary byte values. Encoding to Base64 lets a key, a small image, or a multi-byte string travel through those text-only channels intact.

How the two directions work

Switch between Encode (text → Base64) and Decode (Base64 → text) at the top; the output updates as you type, and Swap feeds the current output back through the opposite direction — handy for confirming a value round-trips. Clear empties the input.

Encoding processes three input bytes at a time and emits four characters, which is why Base64 output is always about 33% larger than the input. When the input length isn't a multiple of three, the last group is padded with one or two = signs to keep it aligned to four.

This tool is Unicode-safe. It encodes text through UTF-8 first, so 한글, 😀, and accented letters survive the trip. That matters because the browser's built-in btoa() throws an error on any character above code point 255 — one of the most common reasons a hand-rolled Base64 snippet breaks the moment someone pastes an emoji.

The decoder is deliberately forgiving: it ignores spaces and line breaks, tolerates missing = padding, and reads either alphabet automatically. If you paste something that isn't valid Base64 at all, the output box shows an error rather than silent garbage.

Standard vs. URL-safe

Standard Base64 uses + and /. Both are a problem in URLs and filenames — / is a path separator and + decodes to a space in query strings. Toggle URL-safe to emit - and _ instead and drop the trailing = padding. That's the "base64url" variant used in JWTs, so if you're building or inspecting a token, this is the toggle you want. You don't need it to decode: the decoder accepts both alphabets either way.

A common misconception

Base64 is encoding, not encryption. Anyone can decode it back to the original in one step — it hides nothing and provides no security. Its job is safe transport, not secrecy. It also doesn't compress; it makes data larger, not smaller.

Everything stays local

Encoding and decoding are pure string operations that run in your browser. Nothing you paste is uploaded, so you can decode a JWT payload, a session token, or an internal API blob without it ever leaving your device.

Where you'll reach for it

Reading the middle segment of a JWT to inspect its claims, embedding a small icon as a data:image/png;base64,… URL, building an HTTP Authorization: Basic header (the Base64 of user:password), or debugging an API that returns Base64-wrapped payloads.

Frequently asked questions

Why does encoding text make it about a third bigger?: Base64 turns every 3 bytes into 4 printable ASCII characters, so the output is always about 33% larger than the input. That overhead is the cost of moving binary safely through text-only channels — it never shrinks data, so use a real compressor if size is the goal.
Can it handle emoji and Korean, or will it break like btoa()?: It encodes through UTF-8 first, so 한글 and 😀 round-trip exactly. The browser's built-in btoa() throws an error on any character above code point 255, which is the usual reason a hand-rolled Base64 snippet breaks the moment someone pastes an emoji.
What's the difference between standard and URL-safe Base64?: Standard uses + and /, which clash with URLs and filenames; URL-safe swaps them for - and _ and drops the trailing = padding. JWTs use the URL-safe (base64url) variant, and the decoder here accepts either alphabet automatically.
Is Base64 a way to hide or protect data?: No — it's reversible encoding, not encryption. Anyone can decode a Base64 string back to the original in one step, so never treat it as secure. Its only job is making binary safe to carry as text.
Why does my decoded output look like garbled characters?: Usually the original bytes weren't UTF-8 text — for example a raw image or a different encoding — so they don't map to readable characters. A genuine text payload decodes back intact; input that isn't valid Base64 shows an error instead.

Privacy

Encoding and decoding are pure local string operations; whatever you paste in — including anything sensitive — is never transmitted anywhere.