🔐 Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 back to text — supports full Unicode (emoji, CJK, accents). Output updates as you type.
URL-safe Base64
-_ instead of +/Replaces + with – and / with _ — safe for URLs, filenames, and JSON without escaping
Strip padding
= signsRemoves trailing = characters — some APIs require unpadded Base64
Input uses URL-safe Base64
-_Converts – back to + and _ back to / before decoding
Process each line independently
Decodes each line as a separate Base64 string — useful for lists of tokens
⚠️
Invalid Base64
Encoding Statistics
Input Bytes
Size Ratio
Base64 adds ~33 % overhead — 3 input bytes become 4 Base64 characters.
Base64 Alphabet & Quick Reference
| Value | Char | Value | Char | Value | Char | Value | Char |
|---|---|---|---|---|---|---|---|
| 0–25 | A–Z |
26–51 | a–z |
52–61 | 0–9 |
62 | + (or – URL) |
| 63 | / (or _ URL) |
Padding | = |
64 chars total | |||
Common Use Cases
- →Email attachments (MIME)
- →Embed images in HTML / CSS as data URIs
- →Store binary data in JSON or XML
- →HTTP Basic Auth header (
user:pass) - →JWT tokens (header.payload.signature)
- →SSH / PGP key encoding
Standard vs URL-safe
| Standard | URL-safe | When to use |
|---|---|---|
+ | - | URLs, filenames |
/ | _ | AWS S3 keys, JWT |
= | optional | Strip for URLs |
Unicode: This tool encodes text as UTF-8 bytes first, then Base64. Decode reverses the process — raw binary Base64 (non-UTF-8) may show replacement characters (�).
The UTF-8 chain and what the options change
Base64 encodes bytes, not characters, so the first step matters. Your text is passed through a TextEncoder to produce UTF-8 bytes, those bytes are converted to a binary string, and that string is passed to the browser's btoa function. Decoding runs the reverse: atob produces a binary string, the bytes are collected into an array, and a TextDecoder turns them back into text. Skipping the UTF-8 step is what causes other tools to fail on anything beyond plain ASCII.
The algorithm itself takes three bytes at a time, 24 bits, and splits them into four six-bit groups, each mapped to one character of the 64-character alphabet. When the input is not a multiple of three bytes, the final group is padded and one or two equals signs are appended to mark how many bytes were real.
The URL-safe option applies RFC 4648 section 5, replacing plus with hyphen and slash with underscore so the result can sit in a URL, a filename or a JSON value without escaping. Stripping padding removes the trailing equals signs. On decode, both substitutions are reversed before the data is parsed.
The algorithm itself takes three bytes at a time, 24 bits, and splits them into four six-bit groups, each mapped to one character of the 64-character alphabet. When the input is not a multiple of three bytes, the final group is padded and one or two equals signs are appended to mark how many bytes were real.
The URL-safe option applies RFC 4648 section 5, replacing plus with hyphen and slash with underscore so the result can sit in a URL, a filename or a JSON value without escaping. Stripping padding removes the trailing equals signs. On decode, both substitutions are reversed before the data is parsed.
Encoding "Hello, World!" and reading the statistics
Type Hello, World! into the input with the mode set to encode. That is 13 characters, all ASCII, so 13 UTF-8 bytes.
Base64 works in groups of three bytes, and 13 divided by 3 is 4 full groups with 1 byte left over, so the output is 5 groups of 4 characters: 20 characters in total. The result is SGVsbG8sIFdvcmxkIQ==, where the two trailing equals signs mark that the last group carried only one real byte.
The statistics panel therefore reads: input 13 bytes, encoded 20 characters, extra characters 7, and a ratio of 154 percent, because 20 divided by 13 is 1.538, rounded to 154. This matches the general rule that Base64 inflates data by about one third.
Turn on strip padding and the output becomes SGVsbG8sIFdvcmxkIQ, 18 characters. Turn on URL-safe and nothing changes here, because this particular output happens to contain no plus or slash characters; strings with those characters would show hyphens and underscores instead.
Switching to decode mode and pasting the encoded string returns the original 13 characters exactly.
Base64 works in groups of three bytes, and 13 divided by 3 is 4 full groups with 1 byte left over, so the output is 5 groups of 4 characters: 20 characters in total. The result is SGVsbG8sIFdvcmxkIQ==, where the two trailing equals signs mark that the last group carried only one real byte.
The statistics panel therefore reads: input 13 bytes, encoded 20 characters, extra characters 7, and a ratio of 154 percent, because 20 divided by 13 is 1.538, rounded to 154. This matches the general rule that Base64 inflates data by about one third.
Turn on strip padding and the output becomes SGVsbG8sIFdvcmxkIQ, 18 characters. Turn on URL-safe and nothing changes here, because this particular output happens to contain no plus or slash characters; strings with those characters would show hyphens and underscores instead.
Switching to decode mode and pasting the encoded string returns the original 13 characters exactly.
Common decoding errors and what Base64 is not
The most frequent decode failure is a URL-safe string decoded without the URL-safe option enabled. Hyphens and underscores are not part of the standard alphabet, so the parse fails; the error message points this out. The second most common cause is stray whitespace or a line break pasted from an email or log, and the third is truncation, since a Base64 string must be a whole number of four-character groups once padding is accounted for.
Line-by-line decoding exists for a specific case: a file or clipboard containing one Base64 value per line, such as a list of tokens. Without it, the whole block including newlines is treated as one string and will usually fail.
It is worth being clear about what Base64 does. It is an encoding, not encryption. Anyone can reverse it instantly, as this page demonstrates, so it provides no confidentiality whatsoever. Its purpose is to move binary data safely through channels that only handle text, such as email bodies, JSON fields, data URLs and HTTP headers. Never use it to obscure passwords, keys or personal data.
Line-by-line decoding exists for a specific case: a file or clipboard containing one Base64 value per line, such as a list of tokens. Without it, the whole block including newlines is treated as one string and will usually fail.
It is worth being clear about what Base64 does. It is an encoding, not encryption. Anyone can reverse it instantly, as this page demonstrates, so it provides no confidentiality whatsoever. Its purpose is to move binary data safely through channels that only handle text, such as email bodies, JSON fields, data URLs and HTTP headers. Never use it to obscure passwords, keys or personal data.
Frequently Asked Questions
Yes. Text is converted to UTF-8 bytes before Base64 encoding and converted back after decoding, so accented letters, Cyrillic, Chinese, Arabic and emoji all survive a round trip unchanged. Tools that skip the UTF-8 step typically fail or corrupt anything outside basic ASCII.
It replaces plus with hyphen and slash with underscore, as defined in RFC 4648 section 5, so the result can appear in a URL path, a query string or a filename without percent-escaping. JSON Web Tokens use this variant. Enable the matching option when decoding such a string.
The usual causes are a URL-safe string decoded without the URL-safe option enabled, stray whitespace or line breaks pasted along with the value, or a string that was truncated. Check that the length forms complete four-character groups once any trailing equals padding is included.
Yes, using the strip padding option when encoding. Some APIs and token formats, including JSON Web Tokens, require unpadded Base64. Decoders that expect padding may then reject the value, so only remove the trailing equals signs when the receiving system specifically asks for unpadded output.
No. It is a reversible encoding designed to carry binary data through text-only channels, and anyone can decode it instantly without a key. It offers no confidentiality. Never use it to hide passwords, API keys or personal data; use real encryption for that.