Convert text to Base64 and back, with correct UTF-8 handling for every language and emoji — entirely inside your browser.
Base64 maps arbitrary bytes onto 64 printable characters so binary data survives channels that only accept text: JSON payloads, HTTP headers, email bodies, data URIs and configuration files. The cost is size — the encoded form is about 33% larger than the original.
The browser's built-in btoa only accepts characters up to U+00FF, so it throws on “ş”, “日” or any emoji. The correct approach — used here — is to encode the string as UTF-8 bytes first, then Base64 those bytes. Decoding reverses both steps.
JWTs and query parameters use a variant where + becomes -, / becomes _, and padding is dropped. Swap those characters back before decoding a token here.
Working with images instead? Use image to Base64 to produce a data URI you can paste into CSS or HTML.
Yes. The text is encoded as UTF-8 before Base64, so Turkish, Chinese, Arabic and emoji all round-trip correctly. Naive implementations that call btoa directly throw on those characters.
No — it is an encoding, not a cipher. Anyone can decode it instantly. Never use Base64 to hide passwords or secrets; it exists to carry binary data safely through text-only channels.
Yes, in the sense that matters: the page has no backend and nothing is transmitted. Encoding happens in your tab, which is exactly why a browser-based tool is safer than an upload-based one for sensitive strings.
Usually padding or stray characters. Base64 length must be a multiple of four, padded with "=", and URL-safe variants replace + and / with - and _ — convert those back before decoding.
Base64 writes four characters for every three input bytes, so the encoded value is roughly one third larger before compression. It is useful for transport through text-only fields, not for reducing size.