Base64 Encoder / Decoder

Base64 maps every three bytes onto four printable characters, so arbitrary binary can travel through channels that only accept text. It is fully reversible by anyone, requires no key, and provides no confidentiality whatsoever.

This gets misunderstood constantly. Base64-encoded credentials in a config file are plaintext credentials with an extra step. The encoding hides them from casual reading and from nothing else.

The size cost is inherent: four characters per three bytes means output is about 33% larger than input, plus padding. That is why base64-embedded images inflate a page more than the same file served separately.

The standard alphabet ends with plus and slash, both of which have meaning inside a URL. The URL-safe variant substitutes minus and underscore, and frequently drops the trailing equals-sign padding as well.

Mixing the two is a routine source of bugs. Discord bot tokens use the URL-safe unpadded form, so a decoder assuming standard base64 fails on any token containing those characters - which is why the same token decodes in one tool and not another.

Discord tokens, JWT authentication headers, data URIs for images, and email attachments all use base64. Being able to encode and decode it quickly saves time when debugging API responses or inspecting payloads.

Base64 is encoding, not encryption. It transforms data into a safe text format but offers no secrecy, since anyone can decode it back. Never treat a base64 string as a way to hide sensitive information.