Base64 encoder
Base64 with both alphabets shown, because the standard one ends in characters that mean something else in a URL — and a string encoded with one and decoded with the other often comes back wrong without complaining. Nothing you type here leaves your browser — it is worked out on your own device, so there is nothing to send and nothing to log.
There are two alphabets, and they are not interchangeable
Standard Base64 ends its 64-character alphabet with + and /. Both of those mean something in a URL — + is a space in form encoding and / is a path separator — so a URL-safe variant exists that uses - and _ instead.
A string encoded with one and decoded with the other is wrong in whichever bytes happened to land on those two characters. It will often decode without complaint, which is worse than failing.
Padding is required in one and optional in the other
The trailing = characters bring the output to a multiple of four. Standard Base64 requires them; the URL-safe variant usually omits them, because = also has meaning in a query string.
A decoder that insists on padding will reject a perfectly good URL-safe string, and one that does not may accept something truncated. Both are common.
It is not compression, and it always grows
Three bytes become four characters, so the output is a third larger before padding. That is the deal: Base64 exists to move arbitrary bytes through channels that only accept text, and the size is what you pay.
It is also not encryption. Base64 is entirely reversible by anybody, provides no secrecy whatever, and the number of systems that have treated it as though it did is genuinely alarming.