What Base64 is for
Base64 takes any sequence of bytes and rewrites it using 64 safe characters: A to Z, a to z, 0 to 9, plus and slash, with = as padding. That makes binary data survive channels built for plain text, which is why you meet it everywhere in development: images embedded in CSS as data URIs, attachments inside emails, the payload sections of JWT tokens, values in HTTP basic authentication headers and binary blobs stored in JSON or XML.
One thing Base64 is not: encryption. There is no key and no secret. Anyone who finds a Base64 string can decode it in a second, so never treat encoding as a way of hiding passwords or personal data. Everything on this page runs in your browser, so whatever you paste here never leaves your device.
How the encoding works
The encoder takes the input 3 bytes (24 bits) at a time and slices that into four 6-bit groups, each of which maps to one character of the 64-character alphabet. When the input is not a multiple of 3 bytes long, the final group is padded out with = signs: two leftover bytes produce one =, one leftover byte produces two. The output is therefore always about a third bigger than the input, which is the price you pay for text safety. A 100-byte input becomes 136 characters.
Why UTF-8 safety matters
The browser's built-in btoa function only accepts characters with code points up to 255, so it throws an error the moment your text contains an emoji or a character like the euro sign, and it quietly encodes characters between 128 and 255 as Latin-1 rather than the UTF-8 the rest of the world expects. This tool sidesteps both problems by converting your text to UTF-8 bytes with TextEncoder first and only then encoding, and by decoding back through TextDecoder afterwards. Accents, pound signs, Chinese characters and emoji all round-trip correctly.
Decoding is validated in both directions: the input must use only the Base64 alphabet with correct padding, and the decoded bytes must be valid UTF-8. If a decode produces bytes that are not text, you are probably looking at an encoded file or image rather than a string, and you will get a clear message saying so instead of mojibake.
Common gotchas
A few things trip people up regularly. URL-safe Base64 (used in JWTs and many APIs) swaps + for - and / for _ so the string can live in a URL without escaping; swap them back before decoding here. Line breaks inserted by email systems every 76 characters are harmless, and this tool strips all whitespace before decoding. And if a string decodes but looks like garbage, check whether it was double-encoded: decoding twice is a surprisingly common fix.
Frequently asked questions
Is my text uploaded anywhere?
No. Encoding and decoding happen entirely in your browser with JavaScript. Tokens, credentials and config values never leave your device, which matters because Base64 strings often contain exactly that sort of material.
Is Base64 encryption?
No. Base64 is an encoding, not encryption. Anyone can decode it instantly with a tool like this one, so it provides no secrecy at all. Its job is to make binary data safe to carry through text-only channels, not to hide it.
Why do some Base64 strings end in one or two equals signs?
That is padding. Base64 turns every 3 bytes into 4 characters, so when the input length is not a multiple of 3 the encoder pads the final group. One leftover byte produces two equals signs and two leftover bytes produce one.
Why does my decode fail with an error?
The input contains characters outside the Base64 alphabet, or its length is wrong after padding. Common causes are truncated strings, URL-safe Base64 that uses minus and underscore instead of plus and slash, and stray line breaks or spaces. This tool strips whitespace for you but cannot repair a truncated string.
Does this handle emoji and accented characters?
Yes. The text is converted to UTF-8 bytes before encoding and decoded back from UTF-8 afterwards, so characters like the pound sign, e acute and emoji survive the round trip. Older tools that skip this step corrupt anything outside basic ASCII.