What Base64 is (and is not)
Base64 represents arbitrary bytes using 64 printable ASCII characters: A-Z, a-z, 0-9, + and /. Every 3 input bytes (24 bits) are split into four 6-bit groups, and each group maps to one character. If the input length is not a multiple of 3, the last group is padded with one or two = signs. That is why the output is always about 33% larger than the input: 4 characters for every 3 bytes, plus up to 2 bytes of padding. A 300 KB image becomes roughly 400 KB of text.
Base64 is an encoding, not encryption. Anyone can decode it instantly, so it offers no protection for passwords, tokens or personal data. Its job is to move binary data through channels that only accept text: email attachments (MIME), JSON payloads, HTTP headers such as Authorization: Basic, and inline images in HTML and CSS via data URIs like data:image/png;base64,iVBORw0KGgo.... JSON Web Tokens (JWT) are three base64url-encoded segments joined by dots.
Unicode, the URL-safe alphabet and line wrapping
The browser's built-in btoa() only accepts single-byte characters and throws on anything else. This tool first converts your text to UTF-8 bytes with TextEncoder, then encodes those bytes, so accented letters, CJK text and emoji round-trip correctly; decoding does the reverse with TextDecoder. The sample sentence is 100 characters but 104 bytes, because the emoji is 4 bytes and the é is 2. Keep in mind that another system reading the same Base64 will only get the same text if it also assumes UTF-8.
Standard Base64 uses + and /, which have special meaning in URLs and file names, and =, which gets percent-encoded. RFC 4648 section 5 defines base64url: - instead of +, _ instead of /, and padding usually omitted. JWTs, OAuth PKCE verifiers and many API keys use it. The decoder here accepts either alphabet, ignores whitespace and line breaks, and restores missing padding automatically.
MIME (RFC 2045) requires Base64 in email bodies to be broken into lines of at most 76 characters separated by CRLF; PEM certificate files use 64. Check "Wrap at 76 characters" when you are building an email part by hand. Decoders ignore the line breaks, so wrapped and unwrapped output decode to the same bytes.
Practical notes
The decoder only produces text. If a decoded string looks like garbage, the data is probably binary (an image, PDF or ZIP) - save it as a file with a proper tool instead. Data URIs are convenient for icons under a few kilobytes, but the browser cannot cache them separately and they inflate your HTML; for anything larger, a normal image file is faster. Everything here runs locally in your browser with no network requests.