Base64 in a sysadmin's day
Base64 is everywhere in operations work: Kubernetes stores every Secret value Base64-encoded, HTTP Basic auth headers are Basic base64(user:pass), certificates travel as Base64 blocks between -----BEGIN markers, and email attachments, SAML assertions and cloud-init user data all use it. This tool encodes and decodes instantly, entirely in your browser, which matters, because the strings you decode are often credentials that should never be pasted into a random website with a backend.
Standard vs. URL-safe
Standard Base64 uses + and /, both of which have special meaning in URLs. The URL-safe variant (RFC 4648 §5, "base64url") substitutes - and _ and usually drops the trailing = padding. JWTs use base64url exclusively, which is why pasting a JWT segment into a strict standard decoder sometimes fails. The decoder here accepts both alphabets and repairs missing padding automatically.
Common gotchas
Two mistakes account for most "corrupt Base64" tickets. First, newlines: base64 on Linux wraps output at 76 columns by default; use base64 -w0 when a consumer expects one line (Kubernetes manifests, for example). Second, UTF-8: JavaScript's raw btoa() throws on any character outside Latin-1. This tool encodes the text to UTF-8 bytes first, so emoji, accented names and CJK text round-trip correctly.
Not encryption
It bears repeating because it appears in real audit findings every year: Base64 is an encoding, not encryption. Anyone can reverse it in milliseconds; you just did. A Base64-encoded password in a config file is a plaintext password with extra steps. If a value needs protecting, it needs a secrets manager or real encryption, not a change of alphabet.