Base64 Encoder Decoder - Free Online Base64 Converter Tool

What is Base64 encoding?

Base64 is a way to turn any data, including binary data like images, into plain text made only of letters, digits, and a few symbols. A base64 encoder converts data into this text form. A base64 decoder turns it back into the original data. Programs use Base64 to move binary data safely through systems, such as email or JSON, that expect plain text.

Base64 uses an alphabet of 64 characters:

• Uppercase letters A–Z (26 characters)
• Lowercase letters a–z (26 characters)
• Digits 0–9 (10 characters)
• Two symbols, usually + and / (2 characters)

Some systems also use an equals sign (=) at the end of the output as padding. Padding is not part of the 64-character alphabet; it just fills out the length.

Why Base64 exists

Many older text protocols, including email (SMTP) and some parts of HTTP, were built to carry 7-bit ASCII text. They can corrupt raw binary bytes, such as the bytes inside a JPEG image. Base64 avoids this by representing every byte using only safe, printable characters. This is why email attachments, images embedded in web pages, and binary fields inside JSON all commonly pass through Base64 first.

Base64 is not compression and not encryption. Encoded output is always larger than the input, and anyone can decode it without a password or key.

How to use this tool

1. Type or paste text into the input box.
2. Choose "Encode to Base64" to convert text into Base64, or "Decode from Base64" to convert a Base64 string back to text.
3. Turn on live conversion to have the output update automatically while typing.
4. Copy the result with the copy button.

The tool reads and writes standard Unicode text, so accented letters, symbols, and emoji encode and decode correctly, not just plain English letters.

How Base64 encoding works

Base64 turns every 3 bytes of input (24 bits) into 4 output characters (each holding 6 bits), because 24 divided by 6 equals 4.

1. Take the input bytes and write them out as binary.
2. Group the bits into chunks of 24 bits (3 bytes).
3. Split each 24-bit chunk into four 6-bit pieces.
4. Look up each 6-bit number (0 to 63) in the Base64 alphabet and write down the matching character.

If the input length is not a multiple of 3, the last chunk is short. The encoder pads it with zero bits, then adds = characters to the output so the result still comes out in groups of 4:

• One leftover byte produces 2 Base64 characters plus ==.
• Two leftover bytes produce 3 Base64 characters plus one =.

Base64 encoding example

Encoding the word "Hello":

1. ASCII values: 72, 101, 108, 108, 111
2. Binary: 01001000 01100101 01101100 01101100 01101111
3. First 3 bytes (24 bits) split into four 6-bit groups: 010010 000110 010101 101100, which are the numbers 18, 6, 21, 44 → characters S, G, V, s.
4. Remaining 2 bytes (16 bits) split into three 6-bit groups, with 2 zero bits added at the end: 011011 000110 111100, which are the numbers 27, 6, 60 → characters b, G, 8.
5. Because 2 bytes were left over, one = is added at the end.
6. Result: SGVsbG8=

Decoding reverses these steps: each character maps back to its 6-bit number, the bits are joined into a stream, and that stream is read back out in 8-bit bytes.

Base64 encoded length formula

For an input of n bytes, the encoded length in characters is:

encoded_length = 4 × ⌈n / 3⌉

where ⌈x⌉ means round up to the nearest whole number. This formula shows why Base64 output is always about a third larger than the input: 4 output characters for every 3 input bytes is a 33% increase.

Where Base64 is used

• Email attachments (MIME). Email was built for text, so file attachments are converted to Base64 before sending, making the attached file about 33% larger than the original.
• Data URIs. Small images can be embedded directly inside HTML or CSS as text, such as data:image/png;base64,iVBORw0KGgo..., avoiding a separate file request. This works best for small files, since large ones bloat the page and cannot be cached separately.
• APIs and JSON. JSON has no native way to hold raw binary data, so binary files sent through a JSON API are often Base64-encoded first.
• HTTP Basic Authentication. The Authorization header encodes a username and password as Base64, for example Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=. This is not secure by itself; the credentials can be read by anyone who intercepts them, so Basic Authentication should only be used over HTTPS.
• JSON Web Tokens (JWT). Each of a JWT's three parts is encoded with Base64URL, a variant safe to place inside a URL.
• Storing binary data as text. Databases or config files that only accept text sometimes hold binary data as a Base64 string.

Base64 compared with other encodings

URL-safe Base64 replaces the standard + and / characters with - and _, because + and / have special meaning inside a URL. It is used for JWTs, URL query parameters, and file names. This tool produces standard Base64 output; converting to the URL-safe form only requires swapping those two characters.

Base32 uses a 32-character alphabet, so each character carries 5 bits instead of 6. It converts every 5 bytes into 8 characters, an overhead of 60% (8 ÷ 5 = 1.6), compared with 33% for Base64. Base32 is chosen when output must be typed by hand or read over the phone, because it avoids mixed-case letters and easily confused characters.

Hexadecimal uses 16 characters (0–9, A–F) and needs 2 characters per byte, doubling the size (100% overhead). It is common for displaying hashes, colors, and MAC addresses, where readability matters more than compact size.

When not to use Base64

Base64 adds size and CPU cost, so it is a poor fit for large files sent over a network; sending the raw binary data directly is smaller and faster. It should never be relied on to hide sensitive information such as passwords or API keys, since decoding it requires no secret. For storing large files, a database's binary column type or a file storage service is usually better than a long Base64 string in a text field.

Common mistakes

• Skipping UTF-8 conversion. Encoding text with accented letters or emoji without first converting to UTF-8 bytes can corrupt the output.
• Stripping padding. Some systems drop the trailing = characters. Most decoders can still work if the string length is padded back out to a multiple of 4, but not all of them accept it, so it is safer to keep the padding.
• Leftover line breaks. Older MIME-based encoders insert a line break every 76 characters; most modern decoders expect one continuous string without them.
• Mixing up variants. Standard Base64 and URL-safe Base64 use different characters for the same two positions in the alphabet; decoding with the wrong variant produces garbage or an error.

Frequently asked questions

Is Base64 a form of encryption? No. It is a reversible text encoding, not encryption. Anyone can decode a Base64 string instantly without a password. Use an encryption algorithm such as AES if data needs to stay secret.

Why does Base64 make data bigger? Because it spends one full character to carry only 6 bits, while a raw byte holds 8 bits. Converting 3 bytes (24 bits) into 4 characters means the output is 4/3, or about 33%, larger than the input.

Can Base64 encode images and other binary files? Yes. Any binary file, including images, PDFs, and audio, can be Base64-encoded and decoded back byte-for-byte. It is commonly used for small images embedded in HTML or CSS, but is a poor choice for large files.

What is the difference between Base64 and Base64URL? Base64URL swaps the standard + and / characters for - and _, so the result is safe to place inside a URL or file name without extra escaping. JWTs use Base64URL for this reason.

Why is my Base64 string giving an "invalid" error when decoding? The most common causes are missing = padding, stray whitespace or line breaks in the string, or characters that do not belong to the Base64 alphabet, such as using + and / when the string was encoded with the URL-safe variant.

Where does Base64 come from? The technique dates back to early schemes for sending binary data through text-only mail systems in the 1980s, and was formally standardized as part of MIME in RFC 2045 in 1996. The current reference specification for Base64, Base32, and Base16 is RFC 4648.