Paste text to encode, or Base64 to decode. Handles Unicode correctly, and nothing you type leaves your browser.
Base64 takes arbitrary binary data and expresses it using only 64 characters that survive text-only channels: A–Z, a–z, 0–9, plus + and /, with = as padding. It exists because a great deal of internet infrastructure was designed to carry text, and pushing raw bytes through it corrupts them.
Email is the original motivation. SMTP was specified for 7-bit ASCII, so an image attached to a message has to be re-expressed in printable characters to arrive intact. The same problem recurs anywhere binary meets text: embedding an image directly in a CSS file as a data URI, putting a certificate in a PEM file, carrying a binary payload inside a JSON field, or passing a small file through an HTTP header.
Three bytes of input are 24 bits. Those 24 bits are re-split into four groups of six, and each six-bit group indexes into the 64-character alphabet. So three bytes become four characters, and the output is always about 33% larger than the input. When the input length is not a multiple of three, the encoder pads with = — one for a two-byte remainder, two for a one-byte remainder.
That padding is why you so often see Base64 strings ending in = or ==, and why a string ending in === is malformed.
The word Man is three bytes: 77, 97, 110. In binary that is 01001101 01100001 01101110. Regrouped into six-bit chunks: 010011 010110 000101 101110, which is 19, 22, 5, 46. Indexing into the alphabet gives TWFu. Three characters in, four out, no padding needed because the length divided evenly.
This deserves stating plainly because it is misunderstood constantly. Base64 provides no confidentiality whatsoever. There is no key, no secret, nothing to break — anyone who sees the string can decode it in one step, exactly as this page does. It is an encoding, a change of representation, in the same category as writing a number in hexadecimal.
The practical consequence: never treat Base64 as a way to hide a password, an API key or personal data. HTTP Basic authentication sends credentials Base64-encoded, which is why it is unsafe over plain HTTP and acceptable only inside TLS. A JWT’s header and payload are Base64url-encoded and fully readable by anyone holding the token — the signature is what makes it trustworthy, not the encoding.
Standard Base64 uses + and /, both of which have meaning in a URL, and =, which also causes trouble in query strings. The base64url variant defined in RFC 4648 substitutes - for + and _ for /, and usually drops the padding. That is what JSON Web Tokens use. If a decode fails on a string containing - or _, convert those back first — or use our URL encoder if the problem is percent-encoding rather than Base64.
Base64 encodes bytes, not characters, so any text has to be turned into bytes first. This tool encodes to UTF-8 before Base64, which is the modern default and handles accented Latin, CJK, Arabic, Devanagari and emoji correctly. Older browser implementations using btoa directly throw an error on anything outside Latin-1, which is why some tools mangle non-English text. If a decoded string comes out as mojibake, a UTF-8 mismatch somewhere in the chain is almost always the reason.
The 33% size penalty is real. Inlining a large image as a data URI makes the containing file a third bigger, blocks it from being cached separately, and blocks it from being compressed well — Base64 output is high-entropy and gzip does poorly on it. For small icons it can be a net win by saving a request; for anything substantial, serve the file normally.
No, and treating it as one is a genuine security mistake. There is no key and no secret — the transformation is completely reversible by anyone, which is exactly what this page does in one step. It changes how data is represented so it can travel through text-only channels. If you need confidentiality you need actual encryption, and if you need to protect data in transit you need TLS.
Padding. The encoder works on three bytes at a time and produces four characters. When the input length is not a multiple of three, the final group is short, and equals signs pad the output to a multiple of four so decoders know how many real bytes the last group holds. A one-byte remainder produces two equals signs, a two-byte remainder produces one, and an exact multiple of three produces none.
Usually one of four things. It is base64url rather than standard Base64 — look for - and _ where + and / should be. The padding was stripped. Whitespace or line breaks were introduced by copying from a wrapped display, though this tool strips those. Or the string was truncated in transit, which is common when it travelled through a field with a length limit.
About 33%, because every three bytes become four characters. A 1 MB image becomes roughly 1.37 MB encoded. It also compresses poorly, so gzip will not recover much of that. For small assets inlined as data URIs the saved HTTP request can still be worth it; for anything over a few kilobytes, serving the binary file directly is faster.
No. The encoding and decoding run entirely in your browser using its built-in functions. Nothing is transmitted, logged or stored, and the page works with the network disconnected. That said, if you are handling genuinely sensitive data, remember that Base64 offers no protection once the string exists — the caution is about where you paste the output, not this page.
Related: URL Encoder and Decoder · IP Subnet Calculator · Binary Calculator · Password Generator