Base64 is an encoding, not encryption
Base64 rewrites arbitrary bytes using 64 characters that survive systems which only handle text: A-Z, a-z, 0-9, plus two more. There is no key and no secret. Anyone who sees the string can read it back in a second, and every browser has a one-line function to do it. If you find a password or an API key stored Base64-encoded, it is stored in plaintext with an extra step. The point of the format is transport, not protection — getting a binary blob through email headers, a JSON field, a data URI or an HTML attribute without anything downstream choking on a byte it did not expect. Both directions here run in your browser; the string you paste is never sent anywhere.
Why accented and non-Latin text breaks elsewhere
The browser's built-in btoa() only accepts characters in the 0-255 range, because it expects one byte per character. Feed it anything above that and it throws, or in some hand-rolled implementations silently truncates to the low byte and gives you a string that decodes to garbage. The correct sequence is to convert the string to UTF-8 bytes first, then Base64 those bytes, and reverse the order on the way back. That is what this tool does, so the output matches what you get from Python's base64.b64encode(s.encode('utf-8')), Java's Base64.getEncoder().encode(s.getBytes(UTF_8)), or base64 on the command line. If another tool gives you a different answer for the same input, the difference is almost always the byte encoding, not the Base64 step.
The URL-safe alphabet
Standard Base64 uses + and /, both of which mean something in a URL — the first is a space in form encoding, the second is a path separator. RFC 4648 section 5 defines a variant that swaps them for - and _ and usually drops the trailing = padding, since the length is recoverable without it. This is what each segment of a JWT uses, and what most token and signed-URL schemes use. Decoding here accepts either alphabet and re-adds missing padding, so you can paste a JWT segment straight in.
The size penalty, and when to pay it
Every three bytes become four characters, so the encoded form is about 33 percent larger, plus up to two characters of padding. Inlining a 40 KB PNG as a data URI costs roughly 54 KB of HTML that cannot be cached separately from the page and cannot be served with its own compression headers. For a small icon that saves a round trip, the trade is usually worth it. Past a few kilobytes it stops being worth it, and past a few tens of kilobytes it is actively worse than a separate file. If you are encoding to get around a size limit rather than a transport limit, Base64 is moving you in the wrong direction.
Questions people ask
Why does my decode produce nonsense characters?
The original bytes were probably not text. Base64 carries any bytes at all, so an encoded PNG, ZIP or protobuf message decodes fine at the byte level and then fails to be UTF-8. When that happens this tool shows the byte count and a hex dump of the start instead of pretending it is a string. The first few bytes usually identify the format: 89 50 4e 47 is PNG, 50 4b 03 04 is ZIP, 25 50 44 46 is PDF.
Another site gives me a different result for the same text.
For pure ASCII the answer is always identical. Any difference means the two tools disagree about how to turn your characters into bytes before encoding. Older implementations use Latin-1 or a system codepage, which produces a shorter string and loses anything outside 0-255. This tool always uses UTF-8, which is what every current API and file format expects.
What are the equals signs at the end?
Padding. Base64 works on groups of three input bytes, so when the input length is not a multiple of three the last group is short and one or two = characters fill the output out to a multiple of four. They carry no data. The URL-safe variant normally omits them and decoders infer the length, which is why this tool re-adds them before decoding rather than rejecting the input.
Can I use this on a token from a real system?
The conversion happens in the page and nothing is uploaded, so nothing leaves your machine. The caveat is your screen rather than the network: the decoded value is displayed in full, which is worth remembering if you are screen sharing or recording. A JWT payload also stays valid after you have decoded it, so decoding is not the same as revoking.