Base64 Encoder / Decoder
Encode text to Base64 or decode it back instantly.
Your result will appear here.This encodes and decodes Base64 in your browser with correct Unicode handling. Base64 represents binary data using 64 printable ASCII characters, which lets binary travel safely through systems that only handle text — email bodies, JSON payloads, data URIs, HTTP headers. It is emphatically not encryption: anyone can decode it instantly, so it provides no confidentiality whatsoever. The encoding takes three bytes at a time and emits four characters, which is why output is always about 33 percent larger than input and why trailing = signs appear when the length is not divisible by three. The Unicode detail trips up most naive implementations: raw btoa() throws on any character above U+00FF, so text must be encoded to UTF-8 bytes first. There is also a URL-safe variant that substitutes - and _ for + and /, used in JWTs, and the two are not interchangeable.
About the Base64 Encoder / Decoder
Encode any text or string to Base64, or decode a Base64 string back to plain text, right in your browser. Our converter is Unicode-safe — emoji, accents, and multilingual text round-trip perfectly — and nothing you paste ever leaves your device.
How to use the Base64 Encoder / Decoder
- 01Pick a mode: Encode (text → Base64) or Decode (Base64 → text).
- 02Paste your input into the editor on the left.
- 03Read the converted result live in the output panel on the right.
- 04Click "Copy" to send the result to your clipboard.
Why use our Base64 Encoder / Decoder
- 01
Two-way conversion
Switch between encoding and decoding with a single click.
- 02
Unicode-safe
Properly handles UTF-8 — emoji and non-ASCII characters survive round trips.
- 03
Clear errors
Invalid Base64 input shows a friendly error instead of failing silently.
- 04
100% private
All conversion runs locally in your browser — your data is never uploaded.
How the encoding works and why output grows by a third
Base64 takes three bytes of input — 24 bits — and re-expresses them as four characters drawn from a 64-symbol alphabet, since each character carries exactly six bits. That three-to-four ratio is why encoded output is always about 33 percent larger than the input, a fixed and unavoidable overhead. When the input length is not divisible by three, the final group is padded with one or two equals signs so the output length stays a multiple of four, which is why encoded strings so often end in = or ==. The alphabet is A–Z, a–z, 0–9 and two extras, conventionally + and /. That last pair causes a specific problem: both characters have special meaning in URLs, so a Base64 string embedded in a query parameter or a path can be mangled. URL-safe Base64, defined in the same standard, substitutes - and _ for them and usually drops the padding, which is why JSON Web Tokens look like Base64 but will not decode with a strict standard decoder.
The Unicode problem that breaks naive implementations
The browser's built-in btoa() function operates on a string of characters each of which must fit in a single byte. Pass it anything outside the Latin-1 range — an emoji, a Chinese character, a Cyrillic name, even a curly quotation mark — and it throws an InvalidCharacterError. Countless implementations fail on exactly this, which is why encoding text that works in testing suddenly breaks the first time a user types an accented name. The correct approach is to convert the string to UTF-8 bytes first and encode those bytes, then reverse the process on the way back. This tool does that, so text in any script round-trips correctly. It is worth understanding because it explains a common class of bug: if a system produces Base64 that decodes to mojibake, the usual cause is that it encoded UTF-16 code units or Latin-1 bytes rather than UTF-8, and the fix is at the encoding end rather than the decoding end.
What Base64 is for, and the security misunderstanding
The legitimate uses are all about transport. Email attachments are Base64-encoded because SMTP was designed for 7-bit text. Data URIs embed small images directly in HTML or CSS, avoiding a network request at the cost of the 33 percent size penalty and losing cacheability — worth it for a tiny icon, counterproductive for a photograph. Binary fields in JSON must be encoded because JSON has no binary type. HTTP Basic authentication encodes credentials, and this is where the misunderstanding does real damage: those credentials are encoded, not protected, and are trivially readable by anyone who sees the header, which is precisely why Basic auth is only acceptable over TLS. The same applies to JSON Web Tokens, whose payload is Base64url and readable by anyone holding the token — the signature prevents tampering, not reading. Never put a secret in Base64 and consider it hidden; use encryption if you need confidentiality.
Base64 variants you will encounter
| Variant | Characters 62 and 63 | Padding | Where it appears |
|---|---|---|---|
| Standard (RFC 4648 §4) | + and / | Yes | Email, data URIs, general use |
| URL-safe (RFC 4648 §5) | - and _ | Usually omitted | JWTs, URL parameters |
| MIME | + and / | Yes | Wrapped at 76 characters |
A JWT will not decode with a strict standard decoder because it uses the URL-safe alphabet without padding.
Frequently asked questions
Is Base64 a form of encryption?
No. It is an encoding that anyone can reverse instantly with no key. It provides zero confidentiality — never use it to protect a secret.
Why is the encoded output larger?
Every three bytes become four characters, so output is about 33% larger than input. That ratio is fixed by the design and cannot be reduced.
What do the equals signs at the end mean?
Padding. When the input length is not a multiple of three, one or two = characters bring the output to a multiple of four.
Does it handle emoji and non-English text?
Yes. Text is converted to UTF-8 bytes before encoding, so any script round-trips correctly. The browser's raw btoa() would throw an error on those characters.
Why does my decoded text look like garbled symbols?
The encoder almost certainly used Latin-1 or UTF-16 rather than UTF-8. The fix belongs at the encoding end — decoding cannot recover the correct bytes.
Why will my JWT not decode?
JWTs use URL-safe Base64, substituting - and _ for + and / and usually dropping padding. A strict standard decoder rejects it.
When should I use a data URI?
For very small assets such as an icon, where saving a network request outweighs the 33% size penalty. For anything large it costs more than it saves and loses caching.
Is HTTP Basic authentication secure?
Only over TLS. The credentials are Base64-encoded, not encrypted, and are readable by anyone who can see the header.
Is my data uploaded?
No. Encoding and decoding run entirely in your browser and nothing is transmitted.
Last updated
Encoding specified in RFC 4648, sections 4 and 5. Unicode handling follows the UTF-8 definition in the Unicode Standard.