Base64 Encode & Decode
Encode text or files to Base64 and back. UTF-8 safe, with base64url and 76-char line wrapping. Runs entirely in your browser.
Waiting for input
How to use
- Paste the text you want to convert into the input box
- Choose the direction: text to Base64, or Base64 back to text
- Turn on base64url (JWTs, URLs, cookies) or 76-character wrapping (MIME) if you need it
- Copy the result from the button at the top right of the output
About this tool
Base64 maps any sequence of bytes onto 64 printable ASCII characters: A to Z, a to z, 0 to 9, then + and /, with = used to pad the output to a whole multiple of four characters. The reason it exists is unglamorous. Early mail protocols and HTTP header fields could only carry seven-bit text reliably, and a byte with the high bit set, or a character such as = or a bare newline, could be rewritten by some relay along the way. Putting the data inside a shell that looks like ordinary text solved that. The mechanism is bit packing rather than substitution: three bytes hold 24 bits, which split cleanly into four groups of six, and each group indexes the alphabet. That is why the output is about a third larger than the input, and why a length that leaves one or two leftover bytes produces one or two padding characters.
The first thing to get right, and the thing most online converters get wrong, is that Base64 works on bytes while text is not bytes. A string has to be turned into bytes by some character encoding before it can be encoded, and the result is only reproducible if everyone agrees on which one. This tool always uses UTF-8. Encode the same Chinese sentence through a GBK pipeline and you get a completely different Base64 string, because the underlying bytes differ, and neither output is wrong. The same trap sits inside JavaScript: btoa and atob are defined over a binary string in which every character must fit in one byte, so passing text containing anything above U+00FF throws InvalidCharacterError, which is why the common one-liner fails on non-English input and appears to work perfectly in test files full of ASCII.
The second source of surprises is that different ecosystems want different dialects. base64url, used by JWTs, cookies and URL or query-string values, swaps + and / for - and _ so that nothing needs escaping in a URL, and usually drops the padding, which is legal because the character count already implies it. MIME and PEM, used by mail attachments and X.509 certificates, want the standard alphabet and the line length capped, at 76 characters for MIME and 64 for PEM, and they were specified with CRLF line endings, which is a frequent source of mismatch when a file passes through a tool that normalises them. Decoders vary in how strict they are: some reject characters outside the alphabet, some ignore whitespace, some tolerate missing padding. This tool accepts standard and URL-safe input, ignores whitespace, tolerates missing padding, and rejects genuinely illegal characters rather than guessing.
Third, and worth repeating: Base64 is encoding, not encryption. There is no key, no secret and no work factor, and any decoder reverses it in one step, so it must never be used to protect anything. It answers the question can this byte sequence travel through a text-only channel, not the question can this data stay private. Two practical consequences follow. Size: expect four characters for every three bytes, so a 1 MB image becomes roughly 1.33 MB of text, which is why large payloads belong in an upload rather than inlined. Choice: if what you have is a checksum, a hash or a key fingerprint that a human will read, hexadecimal is often the better format despite costing two characters per byte, because each byte stands alone and a mistake is visible; if what you have is arbitrary binary data that has to survive a text pipe, Base64 is the cheaper and safer carrier. And if the goal is confidentiality, use a real cipher, optionally followed by Base64 so the ciphertext can be transported.
Frequently asked questions
- Is Base64 encryption?
- No. It is a reversible encoding with no key, and any tool can decode it in one step. If something must stay secret, use a real cipher; Base64 only answers “can this travel through a text-only channel”, never “can nobody read it”.
- Why does one Chinese character become four characters?
- Base64 turns every three bytes into four characters. A Chinese character takes exactly three bytes in UTF-8, so it maps to four Base64 characters, and the total grows to roughly 1.33 times the original size.
- Can I drop the trailing equals signs?
- In standard Base64 the = signs are padding, and strict parsers may reject output without them. base64url, used by JWTs, cookies and URL parameters, normally omits padding anyway. This tool accepts both forms when decoding.
- The same file gave me two different Base64 strings. Is one of them corrupt?
- Almost certainly both are correct encodings of different bytes, because Base64 is a one-to-one mapping and a single byte of difference changes the whole tail of the output. The usual culprits are line endings (a file saved with CRLF instead of LF), a UTF-8 BOM appearing or disappearing at the start, trailing whitespace, and the character encoding itself. Fix the byte-level questions first, encoding and line endings, and the Base64 will become reproducible.
- Can I do this myself in JavaScript?
- Yes, but not with a bare btoa call on text. The reliable pipeline is TextEncoder to get UTF-8 bytes, then map three bytes to four characters with a lookup table. If you insist on btoa you must first turn the bytes into a binary string in chunks, and chunking matters: spreading a large array into String.fromCharCode overflows the call stack, which is why a snippet that works on a short test string fails on a real file. Decoding runs the same path backwards through TextDecoder, whose two defaults are worth knowing: it silently replaces invalid bytes unless fatal is set, and it strips a leading BOM unless ignoreBOM is set, both of which can hand you data that looks fine.