Base64 Encoder and Decoder
Encode and decode Base64 for text and images, with UTF-8 handling, the URL-safe alphabet, Data URL support and file size readouts.
Inlining an image into HTML, pushing binary through a JSON API, working out whether a pasted blob is a picture or just noise - all of it comes down to Base64. The failures are just as predictable: btoa throws on any text outside Latin-1, strings copied out of a certificate or an email body arrive wrapped in line breaks, and + and / have to be escaped before the result can go into a URL.
Encoding and decoding run entirely on the browser's own TextEncoder, TextDecoder and FileReader. An image you drop in is read locally, no upload request is made, and the page keeps working offline. The URL-safe option follows the RFC 4648 - and _ variant, and line breaks or spaces that tagged along with a paste are ignored rather than treated as errors.
Base64 is an encoding, not encryption
Base64 regroups every 3 bytes into 4 characters of 6 bits each and maps them onto A-Z, a-z, 0-9, + and /, padding the tail with = when the input does not divide evenly. No key is involved and the transformation is fully reversible, so anyone holding the string can recover the original bytes. That makes it a transport format and never a protection: passwords, tokens and private fields encoded this way are effectively plain text, and real confidentiality takes a cipher such as AES or RSA with the key managed separately.
Why btoa breaks on non-Latin text
btoa accepts only code points below 256, so a string with an accented character outside Latin-1, an emoji or any CJK text raises InvalidCharacterError. The traditional workaround with escape and unescape produces Latin-1 bytes, which the receiving side reads as UTF-8 and displays as mojibake. The correct route is to turn the string into UTF-8 bytes with TextEncoder and encode those bytes, then reverse the order on the way back: bytes first, TextDecoder second. This mismatch is the usual reason two tools report different Base64 for what looks like the same text.
URL-safe alphabets and stray line breaks
The standard + and / are ambiguous inside URLs, file names and some MIME contexts, so RFC 4648 defines a URL-safe variant that substitutes - and _ and often drops the trailing =; JSON Web Tokens use exactly this form. In the other direction, PEM certificates and email attachments are wrapped every 64 characters or so, and anything copied out of them tends to carry line breaks and spaces that make a naive decoder fail. This tool strips that whitespace before decoding and accepts both alphabets, while still reporting genuinely invalid input such as a length of 1 mod 4 or padding in the middle of the string.
Frequently asked questions
- Can Base64 be used to encrypt data?
- No. There is no key anywhere in the process; it only rewrites bytes as 64 printable characters, and one step reverses it. Sending a password or a private field as Base64 is equivalent to sending it in the clear - it merely looks less readable. Use AES or RSA when confidentiality is the actual requirement.
- How much larger does Base64 make the data?
- About 33 percent. Every 3 bytes become 4 characters, and the = padding adds a little on top, so a 100 KB file encodes to roughly 134 KB. That growth is the main argument against inlining large images into HTML or API payloads.
- Why does btoa throw InvalidCharacterError on non-ASCII text?
- btoa only handles Latin-1 code points and rejects everything above them. Routing the string through escape and unescape gets you past the error but produces Latin-1 bytes, which turn into mojibake when the other side reads them as UTF-8. Encode the string to UTF-8 bytes with TextEncoder and encode those instead.
- What are the downsides of inlining images as Base64?
- The HTML or CSS file grows by a third, the embedded string cannot be cached on its own, and the browser parses it again on every load, so first paint usually gets slower; the image cannot be lazy-loaded either. Keep it for small icons and serve anything larger as a separate file behind a CDN.