Base64 Encoder & Decoder
Encode or decode Base64 with full Unicode support — Arabic, Kurdish, emoji, all of it.
0 chars · 0 bytes
Your result will appear here0 chars · 0 bytes
Base64 always makes data about 33% larger — that's the cost of making binary data text-safe.
Base64 is one of the most widely misunderstood tools in computing, and the misunderstanding is consequential. It is an encoding, not encryption. It scrambles nothing and protects nothing — anyone can decode it instantly, which is exactly the point. Base64 exists to solve a plumbing problem: some systems can only carry plain text, but the data you need to send is binary. Email attachments, data URIs, JSON payloads containing images, and JWT tokens all rely on it to move arbitrary bytes through channels that were only ever designed for readable characters. This tool encodes and decodes entirely in your browser, so nothing you paste travels anywhere.
How the encoder works
Paste text into either field — the encoder produces Base64, and the decoder reverses it. Encoding takes three bytes of input at a time, which is 24 bits, and re-splits those bits into four groups of six. Each 6-bit group maps to one character from a 64-character alphabet: A–Z, a–z, 0–9, plus `+` and `/`. Since only 64 symbols are needed and they are all safe ASCII, the result survives any text-only channel intact. Everything runs locally in your browser; no data is transmitted.
How the encoding works
3 bytes (24 bits) → 4 characters (6 bits each)
"Man" → 01001101 01100001 01101110
→ 010011 010110 000101 101110
→ 19 22 5 46
→ T W F u = "TWFu"
Size increase = 4 ÷ 3 ≈ 133% of original
Padding: '=' fills incomplete groupsThe 4-to-3 ratio is why Base64 always makes data about 33% larger — you are spending four characters to carry three bytes. That overhead is the price of compatibility. The `=` padding appears when your input length is not divisible by three: one leftover byte produces two `=`, two leftover bytes produce one. This is also why embedding a large image as a data URI bloats your HTML: a 100 KB image becomes roughly 133 KB of text that cannot be cached separately.
What to know about Base64
- 1Base64 is not security. It provides zero confidentiality — decoding is a single function call with no key involved. Anyone who says data is "encoded for security" has misunderstood the tool. If you need secrecy, you need encryption; Base64 is transport packaging, not a lock.
- 2Use URL-safe Base64 in URLs. Standard Base64 uses `+` and `/`, both of which have special meaning in URLs and get mangled by percent-encoding. The URL-safe variant substitutes `-` and `_` instead. Mixing the two is a common and confusing source of bugs, because the string looks valid but decodes to garbage.
- 3Data URIs are a real trade-off. Embedding a small icon as Base64 saves an HTTP request, which is worth it under a few kilobytes. Larger assets cost you: the file grows 33%, it cannot be cached independently, and it blocks the HTML parse. Under roughly 2 KB is the usual rule of thumb.
- 4JWT tokens are Base64, not encrypted. The header and payload of any JSON Web Token are plain Base64 and readable by anyone holding the token — paste one into a decoder and you will see the claims. The signature prevents tampering, not reading. Never put secrets in a JWT payload.
- 5Watch out for character encoding when handling non-ASCII text. Base64 operates on bytes, not characters, so Arabic, Chinese, or emoji must be converted to UTF-8 bytes first. This tool handles that correctly, but naive implementations using `btoa()` directly will throw errors on any character above the Latin-1 range.
Frequently asked questions
Is Base64 encryption?
No, and this distinction matters. Base64 is a public, reversible encoding with no key. Anyone can decode any Base64 string instantly using any tool, including this one. It offers no confidentiality whatsoever. Its purpose is compatibility — moving binary data safely through text-only channels. Using it to "hide" a password provides exactly as much protection as writing the password backwards.
Why does Base64 make my data bigger?
Because it spends four output characters to represent every three input bytes, giving an unavoidable 33% increase. Each output character carries only 6 bits of information while occupying a full 8-bit byte of storage — that lost 2 bits per character is exactly where the overhead comes from. It is the cost of restricting yourself to a safe, printable alphabet.
What are the '=' signs at the end?
Padding. Base64 processes input in 3-byte groups, so when your data length is not divisible by three, the final group is incomplete and gets padded to keep the output length a multiple of four. One leftover byte produces two `=`, two leftover bytes produce one, and an exact multiple of three produces none. Some implementations omit padding entirely, which is valid but can break strict decoders.
When should I use a data URI instead of a file?
For small assets — under roughly 2 KB — where saving an HTTP request outweighs the 33% size penalty. Small icons and inline SVGs are good candidates. Larger images are not: they bloat your HTML, cannot be cached separately from the page, and delay rendering. A logo embedded as a 200 KB data URI is downloaded again on every single page load.
Is my data sent to a server?
No. Encoding and decoding both run entirely in your browser using JavaScript. Nothing is transmitted, logged, or stored anywhere. You can verify this by disconnecting from the internet — the tool keeps working, because there is no server component. This matters when you are decoding a token or payload you should not be sharing.