Base64 encoder

Base64 turns three bytes into four printable characters, making it about a third larger than what went in. That third is real where it costs you: on disk, in memory, and in the time something takes to parse. Over the wire it largely is not, because the encoded text uses only 64 symbols and gzip compresses almost all of the expansion back out, so a Base64 payload inside a compressed response is not costing you a third of the transfer, whatever the arithmetic suggests. Judge it on parsing and memory, not bandwidth.

The arithmetic itself is worth knowing for sizing a field. Every three bytes become four characters. A single leftover byte becomes two characters plus ==; two leftover bytes become three plus =. So "Hi". Two bytes. Encodes as SGk=, and any padded Base64 string has a length that is a multiple of four.

The URL-safe variant swaps + and / for - and _ and drops the padding, because the standard alphabet does not survive a URL or a filename intact. It is the same encoding underneath; only the alphabet changes.

Two practical notes. Base64 is an encoding, not encryption: anyone can reverse it instantly, so encoding a password or a token protects nothing at all. And the output here is one unbroken line: MIME historically wrapped Base64 at 76 characters, and a few older decoders still expect those breaks, though nothing in a URL, a header or a JSON field wants them.