Encode and decode Base64 instantly — UTF-8 safe (emoji and every language work), with a URL-safe variant toggle, automatic padding repair on decode, file-to-data-URI conversion for embedding images in code, and a one-click swap to chain operations. Built for developers, works for everyone.
How to use it
- Pick Encode or Decode — output updates live as you type or paste.
- Toggle URL-safe when the Base64 travels in URLs or tokens.
- Encoding an image or small file? Use the file button to get a ready data URI.
Frequently asked questions
What is Base64 used for?
Embedding binary data where only text is allowed: images inside CSS/HTML (data URIs), email attachments, API payloads, and basic data transport in URLs and tokens.
Is Base64 encryption?
No — it is a reversible encoding with zero secrecy. Anyone can decode it instantly. For secrets you need actual encryption.
Why does my Base64 fail to decode?
Usually missing padding (=), stripped characters, or a URL-safe variant — our decoder fixes padding and accepts both variants automatically.
Does encoding work with emoji and other languages?
Yes — the tool is UTF-8 safe, so emoji, Urdu, Hindi, Arabic and every other script encode and decode correctly (naive btoa alone breaks on these).
Developer-adjacent tools: the word counter, case converter and QR generator — all in our free daily tools.
What Base64 is actually for
It converts binary data into text using 64 safe characters, so that data can travel through systems that only handle text. Email attachments, data URIs in CSS, API tokens and certificate files all rely on it.
The critical point: Base64 is an encoding, not encryption. Anyone can decode it in seconds — this page does it instantly with no key. Putting a password in Base64 provides no protection whatsoever. If a system stores credentials that way, that is a vulnerability, not a security measure.
Why encoded data is bigger
Base64 represents every 3 bytes as 4 characters, so output is about 33% larger than input. A 90 KB image becomes roughly 120 KB encoded.
That matters for data URIs. Embedding a small icon directly in CSS saves an HTTP request and is often worth it. Embedding a photograph inflates your stylesheet, blocks rendering while it downloads, and cannot be cached separately. The rough line is a few kilobytes — below it, embedding usually wins; above it, use a normal image file and the compressor.
Standard and URL-safe are different alphabets
Standard Base64 uses + and / as its last two characters. Both have meaning in a URL, so a standard-encoded string breaks when pasted into one.
URL-safe Base64 swaps them for - and _. Same data, different alphabet — and decoding with the wrong one produces garbage rather than an error, which is why this tool offers both explicitly. JWTs use the URL-safe variant, which is why they contain hyphens and underscores rather than plus signs.
What the trailing equals signs mean
Base64 works in blocks of three input bytes. When the input does not divide evenly, the output is padded with = to complete the block — one or two, never three.
They are structural, not decorative. Stripping them is a common cause of “invalid Base64” errors, and some decoders tolerate their absence while others do not.
When decoding fails
Usually one of three things: a character outside the alphabet (often a space introduced by copy-paste or line wrapping), the wrong alphabet for that string, or missing padding. If output looks like readable text that then dissolves into symbols, the input was probably truncated.
Related: the URL encoder solves a different problem — making text safe inside a URL rather than making binary safe as text. The two get confused constantly.