Convert plain text or binary data to Base64-encoded format, or decode a Base64 string back to its original text.
Base64 encodes binary data into 64 ASCII characters. Every 3 bytes of input produce 4 Base64 characters. If input length is not a multiple of 3, = padding is added.
| Character(s) | Index Value(s) |
|---|---|
| A–Z | 0–25 |
| a–z | 26–51 |
| 0–9 | 52–61 |
| + | 62 |
| / | 63 |
| = | Padding |
| Use Case | Description |
|---|---|
| Email attachments | MIME encoding for binary files |
| Data URLs | Embed images in HTML/CSS |
| JSON / APIs | Transmit binary data in JSON |
| HTTP Basic Auth | user:pass encoded in header |
| JWT tokens | Header and payload encoding |
The 64-character alphabet used here was fixed for email in the MIME standard, RFC 2045, in 1996, and its purpose was practical: to carry binary attachments through mail systems that were only trusted with plain ASCII text. That is the whole job of Base64. It changes how data is written, not who can read it, so it is encoding, not encryption. This page converts text to Base64 and back and shows how much the size grows.
The input is turned into UTF-8 bytes and read three at a time, which is 24 bits. Those 24 bits are cut into four 6-bit groups, each a number from 0 to 63, and each number picks a character: A to Z for 0 to 25, a to z for 26 to 51, 0 to 9 for 52 to 61, + for 62 and / for 63. If the last group has only one or two bytes, the output is padded with one or two = signs. Output length is therefore 4 × ceil(n / 3) characters for n bytes.
Worked example with the word Man. The bytes are 77, 97 and 110, which are 01001101 01100001 01101110 in binary. Regrouped in sixes that reads 010011 010110 000101 101110, or 19, 22, 5 and 46, and those map to T, W, F and u. So Man becomes TWFu. For Hello (5 bytes) the formula gives 4 × 2 = 8 characters, SGVsbG8=, with one padding sign.
The Size increase box on the page divides output characters by input bytes and subtracts one. Hello gives 8 / 5 − 1 = 60.0%, and Hello, World! (13 bytes, 20 characters) gives 53.8%. As the text gets longer the figure approaches the theoretical 33.3%: 300 bytes become 400 characters. Because the page counts UTF-8 bytes, café (4 characters, 5 bytes) also shows 60.0%.
Limits worth knowing. The page handles text only, so there is no file or image upload. It uses the standard alphabet with + and /, not the URL-safe variant with - and _. On decoding, the bytes must form valid UTF-8 text, so the Base64 of a PNG or other binary data is reported as an error even though the string itself is valid. It does not wrap lines at 76 characters the way MIME does, and it does nothing to protect the content.
No. Anyone can reverse it in a second without a key. For example, YWRtaW46cGFzc3dvcmQ= decodes to admin:password. HTTP Basic authentication uses Base64 only to format the credentials, which is why it must run over HTTPS.
Padding. Base64 works in blocks of three bytes, so a final block of one byte adds == and a block of two bytes adds one =. A multiple of three bytes needs none. Some systems drop the padding, and many decoders accept that.
JWT parts use the URL-safe alphabet, with - and _ in place of + and /. This decoder only knows the standard one. Swap - for + and _ for / in the string first, and also remember that the decoded payload is JSON and the signature part is raw bytes.
The one-third figure is the long-text limit. Short inputs are inflated by padding and by the rounding up to whole blocks. Compare a 3-byte input at 33.3% with a 5-byte input at 60.0%.
This page encodes the UTF-8 bytes, so é counts as two bytes and café becomes Y2Fmw6k=. A tool that uses Latin-1 sees é as one byte and produces Y2Fm6Q==. Both are correct for their byte encoding, so make sure both sides agree.
Check for characters outside the standard alphabet, a length that leaves an impossible remainder, and decoded bytes that are not UTF-8 text, as with an image or a compressed file. Whitespace is ignored, so line breaks are not the problem.