If you have ever peeked inside a JWT, inspected a data URI in CSS, or opened a raw email attachment, you have met Base64. It is one of the most ubiquitous encodings on the web — and also one of the most misunderstood. Let's fix that.
What Base64 actually is
Base64 is a way to represent binary data using only 64 printable characters: the letters A–Z and a–z, the digits 0–9, and the symbols + and /. (A trailing = appears as padding.) That alphabet is the whole trick — every one of those characters survives any text-only channel unchanged.
The name describes the math: 64 characters can encode 6 bits each (2⁶ = 64). Since computers work in 8-bit bytes, every 3 bytes of input (24 bits) become exactly 4 Base64 characters. When the input is not a multiple of 3 bytes, = signs pad the output to a clean length.
Two consequences fall out of that math:
- The output is about 33% larger than the input — you are spending extra characters to buy safety.
- The mapping is completely reversible. Decode always returns the original bytes, exactly.
Where you meet Base64 every day
Data URIs
When a small image is embedded directly into a stylesheet —
— the browser decodes it on the spot, no network request needed. This kills extra HTTP round-trips for tiny assets, which is why icon systems and email templates love it.
JSON Web Tokens
A JWT looks like three garbled segments separated by dots. The first two are Base64URL-encoded JSON: the header and the payload. That is why developers can open any JWT on jwt.io and read its claims in plaintext — the encoding was never meant to hide anything.
Email attachments
Email was designed for text. To send a photo through a text-based mail pipeline, MIME wraps the binary bytes in Base64 so no intermediate server mangles them.
Text fields that misbehave
Some APIs, older databases, and copy-paste workflows corrupt bytes — trimming whitespace, mangling line endings, or rejecting control characters. Passing data through Base64 makes it immune, because the alphabet contains none of the characters that cause trouble.
The misunderstanding that causes real damage
Base64 is not encryption. Encryption transforms data so it cannot be read without a key; Base64 is a public, symmetric, instant mapping that anyone can reverse — including with the tool on this site. Storing passwords "encoded in Base64" is functionally identical to storing them in plaintext.
If you need secrecy, you need encryption (AES) or, for passwords specifically, a one-way hash designed to be slow (bcrypt, Argon2). If you need transport safety for binary data inside text channels — that is the job Base64 does, and does well.
Standard vs. URL-safe Base64
The standard alphabet includes + and /, which have special meanings inside URLs. A variant called Base64URL replaces them with - and _ (and often drops the padding). This is what JWTs use, because tokens travel in query strings and headers.
Good decoders accept both variants automatically, and tolerate missing padding — worth checking before you blame your data for a decoding error.
Practical pitfalls
- Double encoding. Encoding already-encoded data produces ever-longer strings with lots of trailing padding — a tell-tale sign you encoded twice.
- Invalid characters. A stray space or newline inside a copied token makes decoding fail. Trim the input first.
- Non-UTF-8 text. Emoji and non-Latin characters are multi-byte in UTF-8. A correct tool encodes the UTF-8 bytes, not the raw JavaScript string — this is where naive implementations corrupt emoji.
- Size explosion in HTML. Base64-inlining large images bloats your document, prevents caching, and slows first paint. Inline only small assets.
Try it live
The Base64 & URL Encoder/Decoder handles both directions with full Unicode support — paste text, get clean Base64 (standard or URL-safe), and decode anything back, entirely inside your browser. Nothing you paste is ever uploaded, which also makes it safe for tokens and payloads you would rather not paste into unknown websites.
Frequently asked questions
Why does my encoded string end with one or two = signs? Padding. Input lengths not divisible by 3 leave 1 or 2 bytes for the final group, and = marks fill the remaining character slots. Decoders can usually reconstruct missing padding.
Can I compress by Base64-encoding something? The opposite — it inflates data by ~33%. If you need smaller payloads, compress first (gzip), then encode the compressed bytes.
Why 64 characters and not more? The alphabet was chosen to be printable, email-safe, and unambiguous across old systems. Larger alphabets exist for specific niches (Base85, Base91) but none have the universal support Base64 enjoys.