Base64 Encoder / Decoder
Encode and decode text to and from Base64 instantly. Runs entirely in your browser.
What this page does
Two jobs in one box. Type or paste text and it is encoded to Base64; paste Base64 and it is decoded back to text. Everything happens in your browser, so nothing you paste is uploaded, logged or stored.
The encoder handles non-English text correctly: it turns your text into UTF-8 bytes first, then encodes those bytes, which is why accented letters, emoji and CJK characters survive the round trip instead of turning into garbage.
How to use it
- Paste your text into the top box.
- Click Encode to get Base64 in the lower box, or click Decode to turn Base64 back into text.
- Click Swap to move the output up and feed it back through, which is the fastest way to check a round trip.
- Click Copy to take the result with you.
How Base64 actually works
Base64 takes every 3 bytes (24 bits) of input and rewrites them as
4 characters (4 × 6 bits) drawn from a 64-character alphabet: A-Z, a-z,
0-9, plus + and /. Because 4 characters are used to carry what 3 bytes
held, the encoded form is exactly 33.3% longer than the input.
The input rarely divides evenly by three, so the encoder pads the last group. The rule is mechanical, and this table is the whole of it:
| Leftover input bytes | Encoded characters | Padding | Example |
|---|---|---|---|
| 3 bytes (24 bits) | 4 | none | Man → TWFu |
| 2 bytes (16 bits) | 4 | one = | Ma → TWE= |
| 1 byte (8 bits) | 4 | two == | M → TQ== |
| 0 bytes (empty) | 0 | none | empty input → empty output |
These three lines come from RFC 4648, the standard that defines the encoding, and you can reproduce them here in one click.
Base64 is an encoding, not encryption
This is the single most common misunderstanding about the format. Base64 has no key, no secret and no randomness. Anyone holding the string can decode it instantly, including attackers, search engines and log analysers.
| Base64 | Encryption (for example AES) | |
|---|---|---|
| Reversible by anyone? | Yes, no key needed | No, a key is required |
| Hides meaning? | No | Yes |
| Makes the data longer? | Yes, by about 33% | Yes, by a small amount |
| Right tool for secrets? | Never | Yes |
So if you are tempted to "hide" a password, an API key or a private message by Base64-ing it, do not: that is a string in a costume, not a secret. Use real encryption, and keep the key somewhere the data is not.
Base64 vs base64url
You will meet two dialects. The standard alphabet uses + and /,
which are both meaningful in a URL, so URL-safe variants replace them with - and
_ and usually drop the = padding. The bytes underneath are identical.
That is why a JWT - three dot-separated base64url segments - can be pasted into a URL or a
header without escaping, and why a token with a + in it may decode fine in one
system and fail in another. If a decoder rejects your string, check which alphabet was used
before assuming the data is corrupt.
Why decoded text sometimes looks like garbage
Base64 carries bytes, not characters. If the bytes were never text to begin with - a PNG, a ZIP, a protobuf message - decoding them produces the same bytes back, and any text view of those bytes is meaningless. That is not a bug in the decoder.
The other common cause is a character-encoding mismatch: text written as ISO-8859-1 (or as Windows-1252) and read back as UTF-8 produces the familiar sequences of odd symbols. The fix is to know what the original bytes were, not to re-encode repeatedly.
Where Base64 is the right tool
- Carrying binary inside text. Email attachments (MIME), JSON payloads that must include a file, and configuration files that cannot hold raw bytes.
- Data URIs. A small image can be embedded directly in CSS or HTML as
data:image/png;base64,..., which saves a request at the cost of a larger file. - Transport that mangles bytes. Systems that strip or reinterpret control characters will happily pass the 64 printable characters of Base64.
- Tokens and signatures. Base64url is how a JWT keeps its JSON readable while remaining safe to paste into a header - our JWT decoder takes it from there.
And the rule of thumb for the reverse direction: if the data is already text, Base64 usually makes things worse, not better. It inflates the size by a third and makes the content unreadable for no gain other than transport safety.
Checking your own results
Two habits catch almost every mistake. First, round-trip: encode, then swap and decode,
and confirm you get your original text back byte for byte. Second, compare against a known
vector - encoding the word Man must give TWFu, because that is the
published example in the standard. If your tool disagrees with a published vector, the tool is
wrong, not the standard.
Related tools: this page pairs with the hash generator when you want a one-way digest instead of a reversible encoding, and with the URL encoder when the real problem is escaping a value for a URL rather than carrying bytes through text.
FAQ
Is Base64 a form of encryption?
No. Base64 is a reversible encoding with no key and no secret: anyone can decode it instantly. Never use it to protect a password, a token or private data - use real encryption instead.
Why is Base64 bigger than the original?
It rewrites every 3 bytes as 4 characters, so the output is exactly a third larger, plus up to two padding characters. Encoding 3 bytes gives 4 characters, 4 bytes give 8, and so on.
Why does my decoded text look garbled?
Usually because the original data was not text - an image or archive decodes to the same bytes, which look meaningless as characters. The other common cause is a character-encoding mismatch, such as ISO-8859-1 bytes being read as UTF-8.
What is the difference between Base64 and base64url?
The same bytes, a different alphabet. Base64url replaces + and / with - and _ and usually omits the = padding, so the result can be used inside a URL, a filename or a JWT without escaping.
Does my text get uploaded?
No. Encoding and decoding happen entirely in your browser, so nothing you paste is sent anywhere or stored after you close the page.