Base64 Encoder and Decoder

How to use the base64 encoder and decoder

Paste into the box on the left and the result updates on every keystroke. Encoding reports the UTF-8 byte count of your input, the character count of the output, and the percentage difference between them. Decoding reports the byte count that came back and which alphabet it found.

Unicode is where most encoders break. The browser function btoa() only accepts characters up to U+00FF, so a single emoji or one Arabic word makes it throw. This tool converts your text to UTF-8 bytes first and encodes the bytes, which is the only approach that survives real input.

The size cost is fixed and worth planning around. Four output characters carry 24 bits, which is exactly 3 input bytes, so the output is always the input rounded up to the next multiple of 3 and then multiplied by four thirds. That is why an inline image in a stylesheet is a third larger than the file on disk.

Decoding here is deliberately forgiving about the harmless things. Line breaks are stripped, because MIME wrapped Base64 at 76 columns for decades. Both alphabets are accepted. Missing padding is added back. What it will not do is guess: an unknown character or an impossible length gets a reason, not a truncated answer.

Nothing you paste leaves your browser. There is no upload, no server round trip, no logging, and the text is never written into the page URL, so no shareable link quietly carries it away. That matters more here than on most pages, because the strings people bring to a Base64 tool are so often credentials.

Why Base64 keeps getting mistaken for security

The confusion is understandable. Base64 output looks scrambled, it is full of capital letters and digits, and it appears in the same places real cryptography does: authorization headers, config files, JSON Web Tokens. Looking unreadable to a human is not the same as being unreadable to anyone, and that gap is where the mistake lives.

The standard describes a transport format and never claims confidentiality. A JSON Web Token makes the point well: its header and payload are Base64url, plainly readable by anyone, and only the signature at the end proves the token was not tampered with. The parts you can read were never meant to be secret.

• Need the contents hidden? Encrypt them, then Base64 the ciphertext if the channel needs text.
• Need to prove nothing was altered? Sign or use a message authentication code.
• Need to store a password? Hash it with bcrypt, scrypt or Argon2, never encode it.
• Need to move bytes through a text-only field? That is the job Base64 actually does.

One practical consequence: a secret that has been Base64 encoded and pasted into a chat, a ticket or a log line is a leaked secret. Rotate it. The encoding buys no time at all, because reversing it takes one command and no key.

Standard alphabet or the URL-safe one?

The two alphabets differ in exactly two characters. Section 4 of RFC 4648 defines the standard set, which ends in plus and slash. Section 5 defines the URL and filename safe set, which uses hyphen and underscore in their place. The first 62 characters, the letters and digits, are identical in both.

The reason to care is what plus and slash mean elsewhere. A slash splits a path segment, and a plus is read as a space by anything parsing form-encoded data. Put standard Base64 in a query string without escaping it and a value containing a plus comes back with a space where the plus was.

Padding is the other difference. The equals signs exist so a decoder knows the output length without being told, but they also need escaping in a URL as %3D. Section 5 therefore allows them to be omitted when the length is known from context, which is why most token formats leave them off.

The formula, worked line by line

Base64 is a regrouping, not a calculation. Take the input as a stream of bits, cut it every 6 bits instead of every 8, and read each 6-bit group as a number from 0 to 63. That number picks one character out of the 64 character alphabet, and the whole scheme falls out of that one move.

Six and eight have a lowest common multiple of 24, which is why the unit of work is 3 bytes in and 4 characters out. When the input does not divide by 3 the last group is padded with zero bits and the output is padded with equals signs, so the decoder can tell how many real bytes the final group held.

output characters = ceil(input bytes ÷ 3) × 4
output characters without padding = ceil(input bytes × 4 ÷ 3)
size change = output characters ÷ input bytes − 1
4 characters × 6 bits = 24 bits = 3 bytes

The padding tells the decoder how much of the last group was real. One equals sign means the final 4 characters carried 2 bytes, two equals signs mean they carried 1 byte, and no padding means a full 3. Without that marker a decoder could not distinguish a trailing zero byte from an absent one.

That is also why a Base64 string can never have a length of exactly one more than a multiple of four. Four characters carry three bytes, three characters carry two, two characters carry one, and one character on its own carries nothing at all. A remainder of one is a truncated string, and this tool says so.

Data URIs are the size cost made visible. An inline image in a stylesheet is roughly a third larger than the file it replaces, which can still be the right trade for a small icon that would otherwise cost a network request, and is rarely right for a photograph.

Questions people ask