Home›Developer Tools› Base64 encode / decodeBrowser
Encode and decode Base64
Encodes text to Base64 and back. Text is UTF-8 encoded first, so accented characters, emoji and CJK all round-trip correctly — the naive approach throws on anything outside Latin-1.
Common presets
Each one has its own page explaining where that requirement comes from and what to expect.
How to use it
- 1Pick the direction: text → Base64, or Base64 → text.
- 2Paste or type into the input box.
- 3The result renders live in the Output box as you type — there is no button to press.
- 4Hit Copy to put it on the clipboard.
Frequently asked questions
- What is Base64?
- A way of writing arbitrary bytes using 64 printable ASCII characters (A–Z, a–z, 0–9, + and /), so that data can travel through channels that only accept text — email bodies, JSON fields, data URIs, HTTP headers. Every three bytes become four characters, and = pads the end.
- Is Base64 encryption?
- No, and this is worth being clear about. Base64 is an encoding, not a cipher: there is no key, and anyone who sees the string can decode it in a second — on this page, for instance. Never use it to hide a password or a token.
- Why is the encoded text about a third longer than the original?
- Four output characters carry three input bytes, so the growth is 4/3, roughly 33%, plus padding. That overhead is the price of being text-safe, and it is why you do not want Base64 for large payloads that could be sent as bytes instead.
- Does it handle emoji, accents and Chinese?
- Yes. The text is UTF-8 encoded before it is Base64-encoded, and decoded the same way on the way back. The naive one-line implementation throws on anything outside Latin-1, which is why so many other converters mangle those characters.
- Is this the same as the Base64 in a JWT?
- Almost. JWTs use Base64URL, which swaps + and / for - and _ and drops the padding so the string survives being put in a URL. Feed a raw JWT segment in here and it may not decode. Use the JWT decoder for tokens.