Base64 Encode / Decode
About Base64 Encode / Decode
Two buttons: encode turns text into Base64, decode turns it back. Both run in the browser over UTF-8 bytes, so Chinese and emoji survive the round trip.
First, the thing people get wrong most often: Base64 is not encryption. Anyone can decode it instantly, key or no key. Its job is carrying data through channels that only accept plain text, which is where it came from (email attachments) and where you still meet it today.
Where Base64 shows up
- Data URLs:
<img src="data:image/png;base64,...">embeds an image directly in HTML - HTTP Basic auth: the Authorization header is literally base64(user:password)
- JWTs: header and payload are Base64URL, and yes, decoding the payload shows you its contents
- APIs and storage that refuse raw bytes
When decode fails
The usual suspects, in order: whitespace or line breaks copied into the string; a length that is not a multiple of 4 (standard Base64 pads with =, some tools strip them); and the URL-safe variant that swaps + and / for - and _, which is what JWTs use.
One more thing: decoding garbage rarely produces an error, just gibberish. Gibberish almost always means the input was never valid Base64 to begin with.
Frequently asked questions
Is Base64 encryption?
No. It is an encoding with no key, reversible by anyone. Never treat a Base64 string as protected data, and never use it to hide passwords.
Why is the result longer than my input?
Base64 packs 3 bytes into 4 characters, so text grows by about a third plus padding. That is the cost of staying safe in text-only channels.
Does it work with Chinese?
Yes. Text is converted to UTF-8 bytes before encoding, so Chinese, Japanese and emoji all round-trip correctly. Tools that assume ASCII garble them.
What is Base64URL?
The same alphabet with + and / swapped for - and _, and the padding dropped. It exists because those characters have special meanings in URLs and JWTs.
