About the base64 encoder
Base64 turns arbitrary bytes into 64 printable characters, so data can travel through anything that expects text — an email body, a JSON string, a data URI, an HTTP header. It is an encoding, not encryption: anyone who has the string can read it back, and this page is a demonstration of exactly that.
The reason to use a tool rather than the console is that the browser's own `btoa` is not a text function. It operates on bytes, throws on any character above U+00FF, and cannot encode "₹", "café" or an emoji. Every developer meets this eventually, usually in production, usually with a customer name. This encoder converts your text to UTF-8 bytes first, which is what makes non-Latin input work, and decoding reverses the same path.
The URL-safe option produces base64url, the variant used by JWTs and anything else that travels in a URL or filename. Standard Base64 uses + and /, which are structural characters in a URL, and pads with = which most clients percent-encode. base64url substitutes - and _ and drops the padding entirely. Decoding here accepts both, so a token pasted straight out of a browser's storage decodes without you needing to fix it up first.
Decoding is strict on purpose. If the bytes are valid Base64 but not valid UTF-8 text — an image, a compressed blob, a binary protocol — you get told so, rather than a string of replacement characters that looks like a successful result. Silent corruption is the worst possible failure for a tool like this.
Everything happens in your browser and nothing is uploaded, which matters because the strings people decode are usually tokens, session cookies or basic-auth headers. Those are credentials, and pasting them into someone else's server is a disclosure regardless of what their privacy policy says.