Base64 Encoder
Convert text or files to Base64 with correct Unicode handling — entirely on this device.
Uses - and _ instead of + and /, without padding — for URLs and JWTs.
Press ? for shortcuts
Do it offline:$ printf '%s' 'Hello, World!' | base64
How to use it
- Paste the text you want to encode, or drop a file onto the input pane. The result appears immediately — there is no button to press.
- Pick a text encoding if you need one other than UTF-8. Latin-1 and UTF-16LE produce different bytes, and therefore different Base64, for the same characters.
- Turn on line wrapping (64 or 76 characters) when the consumer requires it — MIME email bodies and PEM files do; JSON values and HTTP headers do not.
- Use Copy for the raw string, Download for a .txt file, or Share to put the whole tool state into a link you can send.
Paste text — or drop a file up to 16 MB — and the Base64 appears as you type. Everything runs on this device: nothing you paste is uploaded. Unicode is handled correctly (UTF-8 by default), which is where most online encoders quietly disagree with each other.
Examples
Hello, World!SGVsbG8sIFdvcmxkIQ==Plain ASCII round-trips identically in every charset.
café ☕Y2Fmw6kg4piVUTF-8 is the default. A Latin-1 encoder gives a different answer for the same text — the #1 cross-tool discrepancy.
The quick brown fox jumps over the lazy dog, then encodes itself for transport.VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZywgdGhl
biBlbmNvZGVzIGl0c2VsZiBmb3IgdHJhbnNwb3J0Lg==64-character line wrapping — identical Base64 with inserted line breaks; SMTP/PEM consumers require it.
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
UTF-8 vs Latin-1 changes the answer
The same text encodes to different Base64 depending on the byte encoding. “café” is Y2Fmw6k= in UTF-8 but Y2Fm6Q== in Latin-1, because é is two bytes in one and a single byte in the other. If another tool gives you a different string, compare charsets before assuming corruption.
Emoji and other astral characters
Characters outside the Basic Multilingual Plane (most emoji) are surrogate pairs in JavaScript and encode as four UTF-8 bytes. A lone half of a surrogate pair cannot be encoded; this tool substitutes U+FFFD and tells you it did so, instead of corrupting output silently.
CRLF vs LF affects the output
Line endings are bytes too. The same visible text with Windows (CRLF) and Unix (LF) endings produces different Base64. The input pane shows a line-ending indicator so the difference is never invisible.
URL-safe variant
The URL-safe alphabet (RFC 4648 §5) replaces + and / with - and _ and drops the = padding, so the result survives URLs, filenames, and JWTs without escaping. It is a different alphabet, not a different encoding — decoders must be told, or must detect it.
Common errors
input contains an unpaired surrogate; it was encoded as U+FFFD- The text contains half of a surrogate pair — usually the result of slicing a string mid-emoji. The broken character was replaced with the Unicode replacement character rather than producing invalid UTF-8.
File is larger than 16 MB. Use the streaming file converter instead.- This page keeps everything in memory and caps input at 16 MB. For larger files, the command line handles any size: base64 < bigfile > out.txt
input contains characters outside Latin-1; they were encoded as '?'- Latin-1 can only represent code points up to U+00FF. Characters beyond that were replaced with a question mark — switch to UTF-8 if you need them preserved.
FAQ
Does this Base64 encoder handle Unicode correctly?
Yes. Text is encoded as UTF-8 by default, so accented characters, CJK text and emoji all produce correct multi-byte sequences. You can switch to Latin-1 or UTF-16LE when a legacy consumer expects those bytes — the output changes accordingly, and that difference is the most common reason two Base64 tools disagree.
What do the = signs at the end mean?
Padding. Base64 turns every 3 input bytes into 4 output characters, and = fills the last group when the input length is not a multiple of 3. One = means the final group carried 2 bytes; two means it carried 1. Padding is required by strict RFC 4648 but many decoders, including ours, accept unpadded input.
When do I need MIME line wrapping?
Only when the consumer demands lines: MIME email bodies wrap at 76 characters and PEM files at 64. Everywhere else — JSON, HTTP headers, data URIs, environment variables — wrapping breaks things. Leave it off unless a specification tells you otherwise.
Is Base64 encryption?
No. Base64 is an encoding, not encryption — it has no key, and anyone can reverse it instantly. It only makes binary data safe to move through text-only channels. Never use Base64 to protect passwords, tokens, or anything secret.