Some things to know before you start:
Base64 turns bytes into text that uses only 64 safe characters: A-Z, a-z, 0-9, + and /. Each character carries 6 bits. So every 3 bytes (24 bits) become 4 characters.
Here is what happens when you encode Hi!:
Text: H i ! Bytes: 72 105 33 Bits: 01001000 01101001 00100001 6-bit groups: 010010 000110 100100 100001 Numbers: 18 6 36 33 Base64: S G k h
The result is SGkh. Number 0 is A, 26 is a and 52 is 0. So 18 is S and 36 is k.
When the input is not a multiple of 3 bytes, the last group is filled with = so the output length is still a multiple of 4:
Hi! (3 bytes) becomes SGkh with no padding.Hi (2 bytes) becomes SGk=.H (1 byte) becomes SA==.The output is always about 33% bigger than the input. The exact length is 4 × (bytes ÷ 3, rounded up). hello world is 11 bytes and becomes 16 characters: aGVsbG8gd29ybGQ=.
Base64 works on bytes, not letters. So the tool first turns your text into UTF-8 bytes, then encodes those. This is why non-English text grows more than you might expect:
| Text | UTF-8 bytes | Base64 from this tool |
|---|---|---|
é | 2 | w6k= |
café | 5 | Y2Fmw6k= |
नमस्ते (6 characters) | 18 | 4KSo4KSu4KS44KWN4KSk4KWH |
😀 | 4 | 8J+YgA== |
The browser's own btoa() function cannot do this alone. btoa("नमस्ते") throws an error, and btoa("é") gives 6Q==, which is the old Latin-1 form. This tool adds the UTF-8 step, so its results match other modern tools and command-line base64. Decode reverses the same steps.
A rare case: text copied from some programs can contain half of an emoji (a broken character). The tool encodes that half as the replacement character � (UTF-8 bytes EF BF BD) and shows a note, so you know the result is not exactly your text.
These results come from the tool's own decode function:
| Input | Result |
|---|---|
SGkh | Hi! |
SGk (padding missing) | Hi. Missing = is fine. A note says the tool added it. |
SG kh, or Base64 split over many lines | Hi!. Spaces and line breaks are ignored. |
SGkh= (wrong padding) | Invalid Base64 string. The = padding at the end is wrong. |
8J-YgA== or 8J-YgA (URL-safe, with - or _) | 😀. The tool reads - as + and _ as /, and says so in a note. |
data:text/plain;base64,SGkh | Invalid Base64 string. The message asks you to remove everything up to and including the comma. |
iVBORw0KGgo= (the start of a PNG image) | No text. A message says the Base64 is valid, but it decodes to binary data (not text): 8 bytes. |
The last row needs a short explanation. Decode must show the result as text, so it checks that the bytes are UTF-8 text. Images, PDFs, zip files and encrypted data are not text. For those, the tool tells you the Base64 is fine but the data is binary, and shows how many bytes it has.
Some systems use a URL-safe form of Base64. It uses - instead of + and _ instead of /, and it often drops the =. JSON Web Tokens (JWTs) use it. Decode reads both forms. It treats - as + and _ as /, and adds any missing = signs. For example, 8J-YgA decodes to 😀. Encode always gives the standard form. To make URL-safe output, change every + to - and every / to _ after encoding, and remove the = signs.
Authorization: Basic dXNlcjpwYXNz is just user:pass in Base64. Paste dXNlcjpwYXNz into the tool and press Decode to see it.eyJhbGciOiJIUzI1NiJ9 decodes to {"alg":"HS256"}. You can paste each part straight into the tool. The third part is a signature in binary, so Decode says it is binary data, not text.data:image/svg+xml;base64,....Base64 has no key and no secret. Anyone can decode it in one step, as the Basic authentication example shows. It only changes how data looks. Do not use it to hide passwords, API keys or personal data. If data must stay private, encrypt it, and send it over HTTPS.
Base64 is also a poor fit for large files. The output is a third bigger. A large image inside a data URI also makes the HTML or CSS file bigger, and the browser cannot cache the image on its own. For anything more than a small icon, a normal image file is usually better.
echo hello | base64 gives aGVsbG8K, but this tool gives aGVsbG8= for hello. echo adds a newline at the end, and the newline is encoded too. Use printf '%s' hello | base64 to match.SGkh becomes U0draA==. Decode it twice to get back to Hi!.data:...;base64, or Basic before you decode.The message under the buttons says which problem it found. Usually the string still has a prefix such as data:image/png;base64, so remove everything up to and including the comma. Other reasons are a character that Base64 does not use, or wrong = padding at the end. URL-safe Base64 with - and _, and missing = padding, are fine, because the tool reads them. If the Base64 is fine but the bytes are not text, such as an image or a PDF, the tool says it decodes to binary data instead.
No. Base64 has no key and anyone can decode it in one step. It only changes how data looks. Use real encryption for passwords, API keys or personal data.
Every 3 bytes become 4 characters, so the output is about 33% bigger. Text in Hindi, Nepali, Chinese or emoji takes 3 or 4 bytes per character in UTF-8. For example, the 6 characters of नमस्ते are 18 bytes, which become 24 Base64 characters.
Yes. The tool turns the text into UTF-8 bytes before it encodes them, and turns the bytes back into UTF-8 text when it decodes. For example, é becomes w6k= and 😀 becomes 8J+YgA==.
Not with this tool. It only has a text box and does not accept files. For pictures, use the Image to Base64 tool on this site, which gives you a ready data URI.
No. Encoding and decoding use JavaScript functions built into your browser, and the page does not send your text anywhere.