Base64 Encoder & Decoder
Convert text to Base64 and back. UTF-8 is handled properly, so accented letters, Chinese characters and emoji survive the round trip.
—
What this tool does
Base64 turns bytes into a string of 64 safe characters so that data can pass through a channel that only accepts text. A JSON field, an XML attribute, an email header and a URL parameter can all carry text, but not raw bytes, so a payload is Base64-encoded first and decoded at the other end. This tool does both directions, and it encodes as UTF-8 so that a character using several bytes is not mangled.
Method
Encoding takes the UTF-8 bytes of your text and maps every three bytes onto four Base64
characters from the alphabet A–Z a–z 0–9 + /, with = padding when the
input length is not a multiple of three. Decoding reverses that and reads the result back as
UTF-8. This is the definition in RFC 4648; whitespace in the input is ignored, and
invalid input is reported rather than silently guessed at.
Example
| Text | Base64 |
|---|---|
Hello | SGVsbG8= |
Hello, café ☕ 👋 | SGVsbG8sIGNhZsOpIOKYlSDwn5GL |
a | YQ== |
Padding, and why it breaks things
Base64 works in groups of three bytes, which become four characters. When the input is not a
multiple of three bytes the final group is short, and it is padded with = so the
output length stays a multiple of four. That is the only reason = appears at the end
of an encoded string — it carries no data.
| Input | Bytes | Encoded | Padding |
|---|---|---|---|
a | 1 | YQ== | two characters |
ab | 2 | YWI= | one character |
abc | 3 | YWJj | none |
abcd | 4 | YWJjZA== | two characters |
Padding is where two systems most often disagree. Some decoders require it and reject input without it; others accept both and fill it in. JWTs deliberately strip it, while many HTTP APIs expect it. If a token or a signature works in one client and fails in another, check padding before anything else. This tool accepts both padded and unpadded input when decoding, and always emits padding when encoding.
Base64 is not encryption
It is worth stating plainly because it is the single most common misunderstanding: Base64 has no key, and anyone can decode it in one step. It does not hide a value, it does not protect it, and it is not a substitute for hashing or encryption. Treat any Base64 string as plaintext — because functionally, it is.
It also does not compress. Every three bytes become four characters, so the output is about 33% larger than the input. That extra size is the price of making arbitrary bytes representable in a text channel, and it is why a large file sent as Base64 may hit a size limit the raw file would have passed. If size matters, compress the bytes before encoding — Base64 output is high-entropy and compresses almost not at all afterwards.
When you need URL-safe Base64 instead
The standard alphabet contains + and /. In a URL, + has
historically meant a space in query strings, and / separates path segments, so
standard Base64 dropped into a URL can arrive at the server altered. RFC 4648 §5 defines a
URL-safe variant that replaces + with - and / with
_, and usually drops the padding. It is the form used by JWT segments, JWK keys and
most OAuth tokens.
The rule of thumb: if the encoded value will sit inside a URL, use the URL-safe alphabet. If it will sit in a JSON string, an email body or a PEM block, use the standard one.
Data URLs
A data URL embeds a resource directly in a document:
data:image/png;base64,iVBORw0KGgo…. The media type comes first, then the marker
;base64, then the encoded bytes. It is handy for small inline images and icons, and
it saves an HTTP request — but it is not free: the data is not cached separately, it inflates the
document by a third, and a large data URL blocks the document from rendering until it is parsed.
For anything beyond a few kilobytes, a separate file is almost always better.
What this tool does not do
- No line wrapping. The output is one continuous string. PEM and MIME require line breaks at 64 or 76 characters; a decoder that expects them will need the alternative.
- No automatic URL-safe conversion. Use the standard alphabet here, and swap
+//for-/_(and drop padding) when the value is going into a URL. - No encryption or compression. Those are separate operations, and applying them in this tool would be misleading about what Base64 provides.
Common inputs that surprise people
- Whitespace is ignored on decode, so a PEM body pasted with its line breaks
decodes correctly — as long as the
-----BEGIN-----markers are removed too. - Emoji and CJK characters expand. They are three or four UTF-8 bytes each, so a short string with emoji encodes to a much longer Base64 string than its visible length suggests.
- Non-UTF-8 input is not recoverable. This tool encodes UTF-8, which is what almost every modern API expects. An old file in Latin-1 or GBK will decode to the wrong characters, because the bytes are reinterpreted as UTF-8 rather than converted.
- Truncated input decodes to garbage or fails. A Base64 string cut short loses a partial group; this tool reports the error rather than returning a plausible-looking wrong answer.
Frequently asked questions
Can I encode a file, not just text?
This page takes text and encodes it as UTF-8 before Base64. For a file, use the image-to-Base64 tool (images) or a file hash/checksum tool; Base64 of arbitrary binary is possible, but a textarea is the wrong interface for megabytes of bytes, and the result would be unreadable anyway.
What is Base64 actually for?
It re-expresses bytes using the 64 characters that survive every text channel — email, JSON, XML, a URL parameter, a configuration file. It is not encryption and does not compress: it makes binary or arbitrary text safe to carry through systems that only accept a limited character set.
Why does my Base64 get longer?
Every three bytes become four characters, so the output is about a third larger, plus padding. That overhead is the cost of the safe character set.
Does it handle accents, Chinese and emoji?
Yes. The text is encoded as UTF-8 first, so a character that takes several bytes is encoded and decoded correctly rather than corrupted. That is the difference between a UTF-8-aware tool and a naive one.
Is my text uploaded?
No. The encoding and decoding use the browser’s own atob and btoa through UTF-8 buffers; the text never leaves the page.
Is Base64 a form of security?
No. Anyone can decode it. Treat it as an encoding, never as protection for a secret.
Go deeper
Longer explanations of the problems this tool solves:
Sources
- RFC 4648, The Base16, Base32, and Base64 Data Encodings.
- RFC 3629, UTF-8, a transformation format of ISO 10646.
Everything runs in your browser — nothing you type is uploaded.