What Base64 actually does
Base64 represents binary data using only 64 printable ASCII characters (A-Z, a-z, 0-9, plus two more symbols, commonly + and /), making it safe to embed in contexts that only reliably handle plain text — email bodies (its original use case), URLs, JSON strings, and HTML attributes like a data URI for an inline image. It does this by regrouping every 3 bytes of input into 4 Base64 characters, each representing 6 bits instead of a byte's 8.
A worked example
Encoding "Hello, World!" (13 characters) produces "SGVsbG8sIFdvcmxkIQ==" — 20 characters, including two "=" padding characters at the end (Base64 pads its output to a multiple of 4 characters when the input isn't a clean multiple of 3 bytes). Decoding that string exactly recovers "Hello, World!" — Base64 is fully reversible with no data loss, unlike a lossy compression format.
Why the output is always larger than the input
Because 3 input bytes become 4 output characters, Base64-encoded data is roughly 4/3 (about 33%) larger than the original — encoding a 44-character string produces 60 characters, a ratio of about 1.36. Short strings often show a slightly higher ratio than the theoretical 4/3 because of padding overhead, but the effect shrinks as the input gets longer. This is the opposite of what people sometimes assume — Base64 is not a compression technique, and using it never makes data smaller.
Why "encoded" doesn't mean "encrypted" or "secure"
Base64 is fully and trivially reversible by anyone — there's no secret key involved, and decoding requires no special knowledge beyond running the same public, standard algorithm in reverse. Base64-encoding sensitive data (a password, an API key) does not protect it in any meaningful sense; it only changes the data's representation, not who can read it. Genuine security requires actual encryption with a secret key, which is an entirely different (and much more involved) operation than Base64 encoding.
Common places Base64 shows up
Email attachments (MIME encoding, its original purpose), embedding small images directly in HTML/CSS via data URIs (avoiding a separate image request, at the cost of the ~33% size increase), encoding binary tokens or credentials for inclusion in a URL or JSON payload (where raw binary bytes could break the format), and various API authentication schemes that need to pass binary-derived values through text-only headers.