What Base64 encoding is
Base64 represents binary data using 64 printable ASCII characters (A–Z, a–z, 0–9, plus + and /). It exists to move bytes safely through systems built for text — email, URLs, JSON, HTTP headers — where raw binary would be mangled or misinterpreted.
The mechanism is simple: take three bytes (24 bits), split them into four 6-bit groups, and map each group to one character. When the input isn't a multiple of three, = padding fills the gap. Because four characters now carry three bytes, the output is roughly 33% larger — Base64 trades size for safety, nothing more.
One thing it is not: secure. Anyone can decode Base64 instantly, so it offers no protection on its own. It's purely a transport format. Everything here runs locally in your browser, so your text never leaves the page.
Base64 vs. Base64URL
Uses + / and = — the classic alphabet for MIME, data URLs, and general transport.
Swaps + → - and / → _ and drops padding so the string is URL- and filename-safe.
Where developers use it
Inlining a small asset
Turn an icon or font into a data URL so it ships inside your CSS or HTML with no extra request.
Reading an auth header
Decode the Base64 in an HTTP Basic Authorization header to see the username:password it carries.
Embedding binary in JSON
Encode a file's bytes to Base64 so they can travel inside a JSON field that only accepts text.
Frequently asked questions
No — and this is the most important thing to know. Base64 is an encoding, not encryption. It's fully reversible by anyone with no key, so it provides zero confidentiality. Never use it to "hide" passwords or secrets — if you need privacy, encrypt with AES first, then Base64 the result for transport.
It encodes every 3 bytes into 4 ASCII characters, so output is about 33% larger than the input. That's the price of turning arbitrary bytes into text that survives systems which only handle plain ASCII.
Base64 works in 3-byte groups that map to 4 characters. When the input length isn't a multiple of three, one or two trailing = signs pad the final group so decoders know how many bytes the last block really represents. URL-safe Base64URL usually omits the padding.
Standard Base64 uses +, /, and = — characters that have special meaning in URLs and filenames. Base64URL swaps + for - and / for _, and usually drops the = padding, so the result is safe to drop straight into a URL. Toggle URL-safe to switch.
Usually a mismatch: the string was URL-safe Base64URL but decoded as standard (or vice-versa), padding is missing, or the bytes weren't UTF-8 text to begin with (e.g. an image or compressed blob). Toggle URL-safe to match how it was produced, and remember not all Base64 decodes to readable text.
Everywhere bytes ride through text channels: data URLs for inline images and fonts, email attachments (MIME), JWT segments, HTTP Basic auth headers, and embedding binary blobs in JSON or XML.
Yes. The text is treated as UTF-8 before encoding, so accented letters, CJK characters, and emoji all round-trip correctly.