🅱️ Base64 Encoder / Decoder
Base64 turns any bytes into 64 safe characters — encode or decode instantly, with correct UTF-8 handling and the URL-safe variant.
20 chars → 32 Base64 chars (~160%)
How the base64 encoder / decoder works
Encoding converts the text to UTF-8 bytes first, then maps every 3 bytes to 4 characters from the 64-character alphabet (A–Z, a–z, 0–9, +, /), padding with =. That UTF-8 step matters: the browser’s raw btoa() corrupts anything beyond Latin-1 — emoji, accents, most languages. Decoding accepts both standard and URL-safe alphabets and tolerates missing padding.
Base64 is encoding, not encryption — anyone can decode it. Its job is transport: making binary or special-character data safe for JSON, URLs, headers and email. The output is ~33% larger than the input, which is the price of the safety. The URL-safe variant (RFC 4648 §5) is what JWTs and URL parameters use.
Frequently asked questions
Is Base64 encryption?
No — it is a reversible transport encoding with zero secrecy. Anyone can decode it instantly. If you need confidentiality, encrypt first; Base64 is only for making bytes safe to transmit.
Why does Base64 output end with = signs?
Padding: input not divisible by 3 bytes leaves a partial final group, padded with one or two =. The URL-safe convention drops the padding, which decoders (including this one) reconstruct.
Why did my emoji break in other Base64 tools?
They used btoa() directly, which only handles Latin-1. Correct encoding converts to UTF-8 bytes first — this tool does, so emoji and non-Latin scripts round-trip cleanly.
What is the URL-safe variant?
The same encoding with + → - and / → _ (and padding dropped), so the result survives inside URLs and filenames. JWTs use it for all three segments.
How much bigger does Base64 make my data?
Exactly 4/3 of the byte length (~33% overhead), plus padding. The tool reports the ratio live.