Base64 shows up everywhere in web development — inline images in CSS, API tokens, email attachments, data embedded in URLs — but its purpose is often misunderstood. It's frequently mistaken for encryption ("I base64'd the password, so it's secure") or compression ("I'll base64 this to make it smaller"). It's neither. Base64 does exactly one thing: it turns binary data into plain text.
The actual problem Base64 solves
A huge number of systems — email (SMTP), URLs, JSON, XML, and older text-only protocols — were designed to carry text, not arbitrary binary data. Binary data can contain byte values that these systems interpret as control characters, line breaks, or invalid encoding, which corrupts the data in transit.
Base64 solves this by mapping every 3 bytes of binary input to 4 printable ASCII characters, drawn from a fixed alphabet of 64 characters (A-Z, a-z, 0-9, +, /, with = used for padding). The result is guaranteed to be plain, printable text that any text-safe system can carry without corruption — at the cost of making the data about 33% larger.
Where you'll actually run into it
Email attachments. SMTP was originally 7-bit text only. Attaching a binary file (an image, a PDF) means encoding it as Base64 text inside the message body, which is why email attachments have always inflated file size somewhat.
Data URIs in CSS/HTML. background-image: url(data:image/png;base64,...) embeds an image directly inside a stylesheet or HTML file instead of a separate request — useful for small icons where saving an extra HTTP request outweighs the size penalty.
Basic Auth and API tokens. The HTTP Authorization: Basic header carries username:password Base64-encoded — not for security (it's trivially reversible), but because HTTP headers must be text, and this is a compact, standard way to pack two text fields into one text value.
JWTs (JSON Web Tokens). Each part of a JWT is a JSON object, Base64-URL-encoded (a URL-safe variant that swaps +// for -/_) so the token can be safely passed in a URL or header.
What Base64 is not
It is not encryption. Anyone can decode Base64 instantly — it's a public, fixed, reversible mapping with no key involved. If you see credentials or sensitive data Base64-encoded and nothing else, treat it as plain text, because functionally it is.
It does not compress data. It's the opposite — Base64 output is always roughly 33% larger than the original binary input, because it's trading 8 bits of information density per byte for 6 (since each output character only encodes 6 bits from the 64-character alphabet).
If you need actual security, use real encryption (like AES) and only Base64-encode the encrypted output afterward, if you need it in text form. If you need actual size reduction, use a real compression algorithm (like gzip) before, not instead of, any Base64 step required for transport.
Try it
GlaeKit's Base64 Encoder/Decoder handles UTF-8 text and files entirely in your browser — nothing is sent to a server.
Frequently asked questions
Is Base64 the same as encryption?
No. Base64 is a reversible encoding with no key or secret involved — anyone can decode it instantly using any standard tool. It provides zero confidentiality.
Why does Base64 output end with = or == sometimes?
Base64 processes input in groups of 3 bytes at a time. When the input length isn't a multiple of 3, the last group is padded with = characters to keep the output a valid, fixed-length block — one = if there's one leftover byte, two if there are two.
Why is my encoded output bigger than the original file?
By design. Every 3 bytes of input become 4 bytes of output, a fixed ~33% expansion — this is the tradeoff for making binary data safe to carry over text-only systems.
What's the difference between standard Base64 and Base64URL?
Standard Base64 uses + and / in its alphabet, both of which have special meaning inside a URL. Base64URL swaps those for - and _ so the encoded string can be used directly inside a URL or filename without escaping.