Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 back to text instantly, with full UTF-8, Unicode, and emoji support. Runs entirely in your browser.
Calculator
Output
UTF-8 ↔ Base64
—
Output Size
— B
Input Size
— B
Size Change
—
Decoding Failed
—
Common causes:
- Contains characters outside the Base64 alphabet (only A–Z, a–z, 0–9,
+,/are valid) - Uses Base64URL characters (
-or_) instead of standard Base64 — try the JWT Decoder if this is a token - The decoded bytes aren’t valid UTF-8 text (may be binary data or a different text encoding)
Operation
—
How Base64 Encoder / Decoder Works
What is Base64?
Base64 is a binary-to-text encoding scheme that represents any data as a string using only 64
printable ASCII characters (A–Z, a–z, 0–9,
+, /, with = as padding). It exists because many systems —
email (MIME), URLs, JSON, XML, HTTP headers — were designed to carry text safely but not arbitrary
binary bytes. Base64 lets binary or special-character data travel through those text-only channels
without corruption.
Base64 is encoding, not encryption. It is fully and trivially reversible by anyone — it provides zero confidentiality. Never use Base64 to "hide" or "protect" sensitive data; use real encryption for that.
How Base64 Encoding Works
Base64 groups input bytes into chunks of 3 (24 bits) and re-slices them into four 6-bit groups,
each mapped to one of 64 characters. Because 6 bits can represent only 64 values, and each output
character carries 6 bits instead of a byte’s 8, Base64 output is always about 33%
larger than the original input. When the input length isn’t a multiple of 3, the
output is padded with one or two trailing = characters to complete the final group.
Worked Example
"Hi" (2 bytes: 01001000 01101001) is padded to 3 bytes and split into
four 6-bit groups, each mapped through the Base64 alphabet, producing SGk= — 4
characters for 2 bytes of input, with one padding character marking the incomplete final group.
Common Uses of Base64
- Email attachments (MIME): binary files are Base64-encoded so they survive text-only SMTP transport.
- Data URIs: small images/fonts embedded directly in CSS or HTML as
data:image/png;base64,..., avoiding an extra HTTP request. - JWT tokens: the header and payload of every
JSON Web Token are Base64URL-encoded (a
URL-safe variant using
-/_instead of+//, and normally omitting padding). - Basic Auth headers: HTTP
Authorization: Basic <base64(user:pass)>. - Storing binary in JSON/XML: both formats are text-only, so binary payloads (images, keys, certificates) are Base64-encoded to fit inside a string field — see the JSON Formatter for inspecting the result.
Base64 vs Base64URL
| Standard Base64 | Base64URL | |
|---|---|---|
| Character 62 | + | - |
| Character 63 | / | _ |
| Padding | = included | Usually omitted |
| Safe in a URL? | No — + and / have URL meaning | Yes |
| Used by | Email, data URIs, Basic Auth | JWTs, URL-embedded tokens |
This tool encodes and decodes standard Base64. If you're working with a JWT specifically, use the dedicated JWT Decoder, which handles the Base64URL variant and parses the claims automatically.
Common Mistakes
- Treating Base64 as encryption. Anyone can decode it instantly — it adds no security whatsoever.
- Forgetting the ~33% size increase. A 3 MB file becomes roughly 4 MB once Base64-encoded — relevant when embedding assets or hitting payload size limits.
- Mixing up Base64 and Base64URL. A JWT segment won't decode correctly with a
standard Base64 decoder if it contains
-or_characters. - Assuming decode always succeeds. Not every string is valid Base64 — this tool reports invalid input as a clear result rather than a cryptic error.
- Losing padding when copying. Some systems strip trailing
=characters; this decoder restores missing padding automatically, but not every decoder does.
Privacy
Encoding and decoding run entirely in your browser via JavaScript — text never leaves your machine while you type. If JavaScript is disabled, the form falls back to a transient server-side computation that is not stored or logged. Input is capped at 1 MB.
Accuracy & Sources
Last reviewed: July 2026. Formula source: RFC 4648 — The Base16, Base32, and Base64 Data Encodings. All calculations run in your browser. No data is sent to any server.
Frequently Asked Questions
Base64 converts binary or special-character data into plain ASCII text so it can travel safely through systems designed for text only — email attachments (MIME), data URIs embedded in CSS/HTML, HTTP Basic Auth headers, and the header/payload segments of JWT tokens. It is not compression and not encryption — just a safe, reversible text representation of binary data.
No. Base64 provides zero confidentiality — it is fully and instantly reversible by anyone, including this tool. It is an encoding format, not an encryption algorithm. Never use Base64 to protect passwords, tokens, or sensitive data; use real encryption (e.g., AES) if confidentiality matters, and treat any Base64 string as fully readable.
Base64 always expands data by roughly 33%, because each 6-bit output character carries less information than a full 8-bit byte. Every 3 bytes of input become 4 characters of output. A 12-byte string encodes to 16 Base64 characters; a 3 MB file becomes about 4 MB once encoded. This overhead is fixed and unavoidable.
The most common cause is mixing up standard Base64 with Base64URL — a JWT or URL-embedded token uses '-' and '_' instead of '+' and '/', which a standard decoder will reject. This tool tolerates whitespace, line breaks, and missing padding automatically, but a genuinely corrupted or truncated string, or one using the URL-safe alphabet, will still be reported as invalid. For JWTs specifically, use the JWT Decoder.
Yes. Text is encoded as UTF-8 before Base64 conversion, so accented characters, Devanagari, Chinese, emoji, and any other Unicode text round-trip correctly through encode and decode. If a decoded byte sequence isn't valid UTF-8, the tool reports it as invalid input rather than showing corrupted text.
No — encoding and decoding run in your browser via JavaScript, and your text never leaves your device while you type. Only if JavaScript is disabled does the form fall back to a transient server-side computation, which is not stored or logged either way.
Standard Base64 uses '+' and '/' as its 63rd and 64th characters and always includes '=' padding — but '+' and '/' have special meaning in URLs, so this alphabet is unsafe to embed in a URL directly. Base64URL replaces them with '-' and '_' and typically omits padding, making it URL-safe. JWTs use Base64URL, which is why a standard Base64 decoder can't read JWT segments — use the JWT Decoder for those instead.