The encoding that carries anything through text-only channels
Base64 is plumbing you meet everywhere once you look: API keys in config files, email attachments under the hood, data-URLs embedding images in CSS, JWT tokens in every auth header, binary blobs in JSON payloads. It exists because vast stretches of computing infrastructure only reliably transport plain text — so Base64 re-spells any data using 64 safe characters (A–Z, a–z, 0–9, +, /) that survive every channel. This tool converts both directions instantly, with correct UTF-8 handling that doesn't mangle Turkish, emoji or any non-ASCII text.
How to encode or decode
- Paste your input — plain text to encode, or a Base64 string to decode.
- Click Encode → Base64 or Decode ← Base64.
- Copy the result. Invalid Base64 input produces a clear error, not silent garbage.
The UTF-8 detail that separates working tools from broken ones
The web's original btoa() function predates emoji and chokes on anything beyond Latin-1 — which is why many online encoders corrupt “çağrı” or “日本語”. This tool encodes text to UTF-8 bytes first, then Base64s those bytes (and reverses the same way), matching what every modern API, JWT library and email system expects. Round-tripping any language, any emoji, any symbol returns exactly what went in.
What Base64 is — and the security myth it drags around
One sentence everyone in tech eventually needs: Base64 is encoding, not encryption. It has no key and no secret; decoding requires only knowing it's Base64 (and the telltale A-Za-z0-9 texture with = padding makes that obvious). “We Base64 the password” is a security joke, not a measure. Its legitimate jobs are transport and embedding: making binary safe for JSON, fitting images into data-URLs, packaging credentials in HTTP Basic auth headers (over TLS, which provides the actual secrecy), and the payload sections of JWTs — which is why pasting a JWT's middle segment into the decoder here reads out its claims in plain JSON.
Field notes
- Size cost: Base64 output is ~33% larger than the input — the price of the 64-character alphabet.
- Whitespace in pasted Base64 (line wraps from emails) is tolerated by the decoder.
- The
=signs at the end are padding, not data — a normal part of the format. - URL-safe variant (with - and _ instead of + and /) appears in JWTs; replace those two characters before decoding if needed.
Two buttons, both directions, no mangled characters — the daily-driver version of an encoding you'll never stop meeting.
Quick reference
| Property | Detail |
|---|---|
| Directions | Text → Base64 and Base64 → text |
| Unicode | Full UTF-8 — Turkish, CJK, emoji all safe |
| Alphabet | A–Z a–z 0–9 + / with = padding |
| Size overhead | +33% when encoding |
| Security | Encoding only — NOT encryption |
| Error handling | Invalid Base64 reported clearly |
| Processing | 100% in-browser, no upload |
Frequently asked questions
Is Base64 a form of encryption?
No — this is the most important fact about it. There's no key; anyone can decode it instantly. It exists to make data transport-safe, not secret. For secrecy you need actual encryption (TLS, AES, age/GPG).
Why do other encoders corrupt my non-English text?
They use the legacy btoa() path, which only handles Latin-1. This tool converts text through UTF-8 bytes first — the modern standard — so çğıöşü, Cyrillic, CJK and emoji round-trip perfectly.
Can I decode a JWT token here?
The header and payload segments, yes — split the token on the dots, replace - with + and _ with /, and decode each segment to read its JSON. The third segment is a binary signature and won't read as text.
What are the = signs at the end of my output?
Padding. Base64 works in 3-byte blocks; when input length isn't divisible by 3, one or two = characters pad the final block. They're part of the valid format — keep them.