About this tool
This Base64 decoder and encoder converts text to Base64 and back in your browser. Text is read as UTF-8, so accents, non-Latin scripts and emoji round-trip correctly. It also handles the URL-safe alphabet used by JWTs, optional = padding, 76-character MIME line wrapping, and whole files of any type. When a decode fails, the error names the character and its position instead of just saying the input is invalid. Nothing you paste or open is uploaded.
How to use the Base64 encoder and decoder
- Base64 encode: type or paste text and click Encode to Base64. To encode an image, PDF or any other file, click Encode a file to Base64.
- Base64 decode: paste the Base64 string and click Decode from Base64. Line breaks and spaces are skipped unless you untick that option, and a leading
data:…;base64,prefix is removed for you. - Pick the variant the other system expects: tick URL-safe alphabet for base64url, and Leave out = padding if it wants no padding.
- Copy or download the result. If the decoded data is a file rather than text, download it as a file.
What is Base64, and how does Base64 encoding work?
Base64 is a way of writing any sequence of bytes using only 64 printable ASCII characters: A–Z, a–z, 0–9, + and /, plus = for padding. It is defined in RFC 4648. The encoder takes the input 3 bytes (24 bits) at a time, splits those 24 bits into four 6-bit groups, and uses each group's value, 0 to 63, as an index into the alphabet. So every 3 bytes become 4 characters. Decoding runs the same steps backwards.
Worked example: Hello, café
The text already in the box, Hello, café, is 11 characters but 12 bytes in UTF-8, because é is stored as two bytes, C3 A9. The first three bytes are H, e and l:
| Step | Value |
|---|---|
| Bytes (hex) | 48 65 6C |
| Bits | 01001000 01100101 01101100 |
| Regrouped into 6 bits | 010010 000110 010101 101100 |
| Index values | 18 6 21 44 |
| Characters | S G V s |
Repeating that for the other three groups gives SGVsbG8sIGNhZsOp: 12 bytes in, 16 characters out, and no padding because 12 is a multiple of 3. Decode that string and you get Hello, café back.
Padding: what the = signs mean
When the input length is not a multiple of 3, the last group is short. RFC 4648 says a final group of 1 byte becomes two characters followed by ==, and a final group of 2 bytes becomes three characters followed by =. Its test vectors show this: f encodes to Zg==, fo to Zm8= and foo to Zm9v. Add an exclamation mark to the example and Hello, café! (13 bytes) becomes SGVsbG8sIGNhZsOpIQ==. Padding carries no data, so some formats drop it; this decoder accepts input with or without it.
The 4/3 size overhead
Because 3 bytes become 4 characters, Base64 output is about 33% larger than the input: exactly 4 × ceil(n ÷ 3) characters for n bytes, before any line breaks are added.
| Input size (bytes) | Base64 length (characters) |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
| 1,048,576 (1 MiB) | 1,398,104 |
Email adds a little more: MIME (RFC 2045) requires Base64 lines of no more than 76 characters, so each line also ends with a line break. The wrap option here inserts a CRLF after every 76 characters.
Base64 is encoding, not encryption
Base64 has no key and no secret. Anyone who has a Base64 string can decode it, exactly as this page does. It is used to move bytes safely through systems that only handle text, not to hide them. A password or API token written in Base64 is still in plain sight, and an HTTP Basic authentication header is only Base64 of username:password, which is why it must be sent over HTTPS. If you need to protect data, encrypt it; if you need a fingerprint of it, use a hash such as SHA-256 from the Hash Generator.
Where Base64 is used
- Data URIs. A small image or font can be placed straight into HTML or CSS as
data:image/png;base64,…. The Image to Base64 converter builds these with the right MIME type, and Base64 to Image previews one. - Email attachments. MIME sends attachments as Base64 text with
Content-Transfer-Encoding: base64, wrapped at 76 characters. - JWTs and URLs. JSON Web Tokens use base64url: the URL-safe alphabet with the trailing
=removed, as defined in RFC 7515. Tick URL-safe alphabet to decode one part here, or use the JWT Decoder to read all of a token's claims at once. - APIs and config files. JSON and YAML have no binary type, so certificates, keys and file contents are often stored as Base64 strings.
URL-safe Base64 (base64url)
Standard Base64 uses + and /, which have special meaning in URLs and file paths. RFC 4648 section 5 defines a second alphabet that is identical except that value 62 is - and value 63 is _. For example, ??? encodes to Pz8/ in standard Base64 and Pz8_ in base64url. The two alphabets are not interchangeable, so tick the URL-safe option for both encoding and decoding when a system uses base64url.
Common Base64 decode errors
- Wrong alphabet. A
-or_in standard mode, or a+or/in URL-safe mode, is rejected, as RFC 4648 requires for characters outside the alphabet. The error says which option to switch. - Impossible length. If the characters (not counting padding) leave a remainder of 1 when divided by 4, the last character holds only 6 bits, which cannot make a byte. A character was lost when the string was copied.
- Misplaced padding.
=may only appear at the end, at most twice, and padded input must be a multiple of 4 characters long. Two Base64 strings pasted back to back often trigger this. - Percent signs.
%2Bor%3Din the input means the Base64 was URL-encoded on top. Decode it with the URL Decoder first. - Binary data, not text. If the decoded bytes are not valid UTF-8, they are a file such as an image, a PDF or a ZIP. The data is fine; download it as a file instead of reading it as text.
Frequently asked questions
Base64 is a way of writing any bytes using 64 printable characters: A to Z, a to z, 0 to 9, + and /, with = as padding. It is defined in RFC 4648. Every 3 bytes of input become 4 characters, so binary data such as images or keys can travel through systems that only accept text.
It is used to put binary data where only text is allowed: images and fonts in data URIs, email attachments in MIME, binary values inside JSON or YAML, the parts of a JSON Web Token (in the URL-safe base64url form) and HTTP Basic authentication headers.
No. Base64 is an encoding, not encryption. It has no key, and anyone can decode it in a second. Never rely on it to hide passwords, tokens or personal data; encrypt the data instead, and send Basic authentication headers only over HTTPS.
The error message names the character and its position. The usual causes are URL-safe characters (- or _) in standard mode, a string with one character missing, = padding in the middle when two strings were joined, or percent-escapes such as %3D from URL encoding. Valid Base64 that holds a file rather than text can be downloaded instead.
Tick URL-safe alphabet, paste the string and click Decode from Base64. URL-safe Base64, also called base64url, uses - and _ instead of + and /. Missing = padding is fine, because the decoder accepts input with or without it. For a whole JWT, use the JWT Decoder, which splits the token at the dots.
Yes. If the decoded bytes are not UTF-8 text, the tool says so, names common file types such as PNG, JPEG, GIF, PDF or ZIP, and lets you download the bytes as a file. To see an image on screen, paste it into the Base64 to Image tool instead.
Every 3 bytes become 4 characters, and the last group is padded to a full 4, so n bytes become 4 times ceil(n / 3) characters. 100 bytes become 136 characters and 1,000 bytes become 1,336, a growth of about one third. MIME line breaks add a little more.