Base64 Encoder and Decoder

What base64 is

Base64 (RFC 4648) writes any bytes using 64 printable characters: A to Z, a to z, 0 to 9, + and /, with = as padding. Every 3 bytes become 4 characters, so encoded data is about a third larger than the original, and it is an encoding, not encryption: anyone can decode it.

It exists to carry binary data through channels built for text: email attachments (MIME), certificates and keys (PEM), images inlined in CSS and HTML (data: URIs), JSON fields, HTTP Basic auth headers and JWTs.

How encoding works

The bytes are read three at a time, 24 bits, and split into four 6-bit numbers, each picking one character from the alphabet. When the input is not a multiple of three, the last group is padded: one leftover byte gives two characters and ==, two leftover bytes give three characters and =.

Text has to become bytes first, and the result depends on the character encoding. This tool always uses UTF-8, the encoding the web and Linux use, so accents, CJK and emoji round-trip:

Standard and URL-safe base64

The standard alphabet's + and / mean something in URLs and file names, so RFC 4648 §5 defines a URL-safe alphabet with - and _ in their place. It usually drops the padding too: JWTs, for example, are three unpadded URL-safe strings. A valid string uses one alphabet or the other, never both; the decoder accepts either and says which it saw.

Line breaks

MIME (RFC 2045) breaks lines at 76 characters, PEM (RFC 7468) at 64. GNU base64 wraps at 76 by default, and openssl base64 at 64. Decoders ignore the breaks, and so does this one; choose one line when the result goes into JSON, an environment variable or a URL.

Worked examples on the command line

printf '%s' 'Hello' | base64              # SGVsbG8=
printf '%s' 'SGVsbG8=' | base64 -d        # Hello
echo 'Hello' | base64                     # SGVsbG8K: echo added a newline
base64 -w 0 logo.png > logo.b64           # one line (GNU); macOS: base64 -i logo.png
openssl base64 -A -in logo.png            # one line with OpenSSL
printf '%s' 'SGVsbG8' | base64 -d         # missing padding: "invalid input"

In a browser or Node.js, btoa() only takes Latin-1 text; encode with TextEncoder first, or use Buffer.from(text).toString('base64') in Node.

Common errors and how to fix them

• base64: invalid input: the data has URL-safe characters, lost its padding, or has text around it. Swap -_ for +/ and add = until the length is a multiple of four, or paste it here to see the exact position.
• An extra K or o= at the end: the input had a trailing newline, usually from echo. Use printf '%s' or echo -n.
• Accented letters come out as é or similar: the bytes were decoded as Latin-1 instead of UTF-8, as atob() does. Decode the bytes with TextDecoder.
• btoa throws InvalidCharacterError: the string has characters outside Latin-1, such as emoji. Encode it to UTF-8 bytes first.
• The decoded file will not open: check the type the decoder detects from the first bytes (PNG, JPEG, GIF, PDF, ZIP, gzip); a data: URI's media type can be wrong while the bytes are right.

Where base64 turns up on a server

SSH public keys in authorized_keys are base64 after the key type, certificates are base64 between their PEM lines (read them with the SSL certificate decoder), and JWTs are three URL-safe parts (use the JWT decoder). Shipown's deploy users feature assigns those SSH public keys to non-root accounts without you editing authorized_keys by hand.