Worth stating plainly, because it gets misused this way constantly. Base64 is an encoding — a reversible mapping with no key. Anyone can decode it instantly, including this page. It offers exactly zero confidentiality.
If you find credentials base64-encoded in a config file, they are stored in plaintext for all practical purposes. HTTP Basic authentication is base64, which is why it is only acceptable over TLS.
The browser's built-in btoa() throws on any character above U+00FF, which is why so many quick base64 tools break on an em dash, an accented name or an emoji. This encodes to UTF-8 bytes first, so the full Unicode range works. The default text above contains an em dash specifically so you can see it round-trip.
Standard base64 (RFC 4648 §4) uses +, / and =. All three are awkward in a URL: + can decode as a space in a query string, / reads as a path separator, and = collides with parameter syntax.
URL-safe base64 (§5) substitutes - for + and _ for /, and usually drops the padding. This is what JWTs use — which is why a JWT's three segments contain no +, / or =. Decoding here accepts either variant and restores missing padding automatically.
Base64 turns every 3 bytes into 4 characters, so output is about 33% larger than input. That is worth remembering before base64-ing an image into a data URI or an email attachment — a 4 MB photo becomes roughly 5.4 MB on the wire.
Email attachments (MIME), data URIs in CSS and HTML, JWT segments, HTTP Basic auth headers, TLS certificates in PEM form, SSH public keys, and Kubernetes secrets — which are base64-encoded, not encrypted, a distinction that has surprised a lot of people mid-audit.
We do managed IT, networking and security for businesses across Central Oregon.
Managed IT Services Call 541-508-8797