User Guide
Pick a direction
Encode to Base64 turns text into the A–Z, a–z, 0–9, + and / alphabet. Decode from Base64 reverses it. The mode buttons sit above the input box.
Paste your input
Type or paste into the box. The example buttons load a sample of text, Base64 or a URL if you want to see the shape of the output before committing your own data.
Press Process
Conversion is instant and happens in this tab. Accented characters, emoji and non-Latin scripts are handled correctly — the tool encodes to UTF-8 first, which is the step naive implementations skip.
Read the result
Copy it, or download it as a file if it is long. Encoded output is always about a third larger than the input; that is inherent to the format, not a setting.
If decoding fails
The usual causes are missing = padding, stray whitespace or line breaks from an email, or a URL-safe string using - and _ instead of + and /. Replace those two characters and try again.
Remember what it is not
Base64 is an encoding, not encryption. Anyone can decode it in one step. Never use it to hide a password, an API key or anything else that matters.
About the Base64 Encoder and Decoder
Base64 converts arbitrary binary data into 64 printable characters so it can travel through systems that only handle text. It was standardised in RFC 4648 and it is everywhere: email attachments, data URIs, JSON payloads, JWTs, HTTP basic authentication, certificate files.
How it works
The mechanism is simple arithmetic. Base64 takes three bytes — 24 bits — and redivides them into four 6-bit groups. Each group indexes into a 64-character alphabet: A–Z, a–z, 0–9, plus + and /.
Three bytes in, four characters out. That ratio is the single most useful thing to know about the format, because it means encoded data is always about 33% larger than the original. When the input length is not a multiple of three, = characters pad the final group — which is why so many Base64 strings end in one or two equals signs.
| Input | Bytes | Output | Padding |
|---|---|---|---|
Man |
3 | TWFu |
none |
Ma |
2 | TWE= |
one = |
M |
1 | TQ== |
two = |
The thing people get wrong
Base64 is not encryption and provides no security whatsoever. It is a reversible transformation with no key. Anyone who sees the string can decode it in one step, including on this page.
This matters because Base64 looks scrambled, and that appearance has caused real breaches. HTTP basic authentication sends username:password as plain Base64 — which is why it is only acceptable over HTTPS, where TLS provides the actual protection. If you need secrecy, encrypt. If you need to prove something has not been altered, use a hash from the Hash Generator. Base64 solves neither problem.
Unicode, and why other tools mangle it
The browser’s built-in btoa() function only accepts characters in the Latin-1 range. Feed it an emoji, a Chinese character or even a curly apostrophe and it throws an error or produces nonsense. This tool encodes the text to UTF-8 first, so café, 中文 and emoji all round-trip correctly. The MDN Base64 reference documents the underlying limitation.
URL-safe Base64
Standard Base64 uses + and /, and both have meaning inside a URL — + can be read as a space, / as a path separator. RFC 4648 therefore also defines a URL-safe alphabet substituting - and _, with padding often dropped.
That variant is what JWTs use. If a string containing - or _ will not decode here, swap them back to + and / and add = until the length is a multiple of four. For tokens specifically, the JWT Decoder handles this automatically.
Where you will meet it
Data URIs embed small images directly in CSS or HTML, saving a request at the cost of 33% more bytes. Email attachments are Base64 because SMTP was designed for 7-bit text. PEM certificates are Base64 between BEGIN and END lines. JSON APIs use it to carry binary blobs, since JSON itself has no binary type.
Privacy
Everything runs in JavaScript inside this page. Nothing you paste is transmitted, logged or stored — which is the reason it is safe to use on data you would not paste into a random website.
Frequently Asked Questions
Is Base64 a form of encryption?
No, and this misunderstanding causes real security problems. Base64 is a reversible encoding with no key — anyone can decode it instantly. It looks scrambled, which is exactly why people wrongly trust it to hide passwords and API keys.
Why is my encoded text bigger than the original?
Because Base64 turns every 3 bytes into 4 characters, which is a fixed 33% increase. It is inherent to the format and no setting can avoid it. That overhead is the price of making binary data survive text-only channels.
What do the equals signs at the end mean?
Padding. Base64 works in 3-byte groups, so when the input length is not a multiple of 3, one or two = characters complete the final group. Removing them will usually break decoding.
Why will my string not decode?
Most often missing = padding, stray whitespace or line breaks picked up from an email, or a URL-safe string using – and _ instead of + and /. Swap those two characters back and add padding until the length divides by four.
Does this handle emoji and non-English text?
Yes. The text is encoded to UTF-8 before Base64 is applied, so accented characters, emoji and non-Latin scripts round-trip correctly. Tools that call the browser’s btoa() directly fail on all of these.
What is URL-safe Base64?
A variant defined in RFC 4648 that replaces + with – and / with _, because the standard characters have their own meaning inside a URL. JWTs use it. Padding is often dropped as well.
Can I safely Base64 an API key before storing it?
No. That provides no protection at all — it is a one-step reversal for anyone with the string. Use proper encryption, or a secrets manager, and keep keys out of client-side code entirely.
Is my data sent to a server?
No. The conversion runs in JavaScript inside this page. Nothing you paste is transmitted, logged or stored, which is what makes it reasonable to use on data you would not paste elsewhere.