Base64 is the least glamorous and most widely used encoding in software. It was designed for an era when you sent binary through channels that only reliably carried text, and it survived because it converts any byte string into 64 printable ASCII characters, needs no escaping, cannot corrupt a line-oriented protocol, and is trivial to invert in any language that has a byte array. You meet it in three places more than any other. Data URLs, where a small image is written into a CSS background or an HTML attribute as data:image/png;base64, followed by the file itself. Basic authentication, where a username and password are Base64 encoded into an HTTP header. And JSON Web Tokens, where the header and the payload are Base64 encoded, in a slightly different alphabet, for exactly one day. Every one of those is a place where the encoding has to be exactly right and where getting it wrong produces output that looks plausible until something else breaks. It runs in this tab, which matters more here than in most tools: Base64 is routinely applied to things that look like secrets.
What Base64 does, and what it definitely does not
The algorithm is defined in RFC 4648. It takes three bytes at a time, 24 bits, and splits them into four 6-bit numbers, each of which indexes a 64-character alphabet: A to Z, a to z, 0 to 9, plus and slash. When the input does not divide evenly into threes, the last group is padded with equals signs. Three consequences follow, and they are the whole story. First, the output is one third larger than the input, always, so Base64 is not compression and never will be. Second, it is completely reversible, by anyone, without a key, which means it is not encryption. A lock and a cardboard box differ only in that people believe in the lock. Third, the output looks random because the algorithm deliberately mixes bits from three different input bytes into each output character, which hides the structure of the file from the eye. That last property is why Base64 was used to disguise payloads, and why scanners exist that decode it automatically.
UTF-8, padding and the mistakes that look like working output
Three specific traps. The first is text. The browser's btoa function takes a binary string and throws an error the moment it sees a character above U+00FF, so btoa of any Chinese, Japanese or emoji text fails outright; the correct route is to encode the string to UTF-8 bytes with a TextEncoder first, then Base64 those bytes. The popular workaround of wrapping the string in encodeURIComponent and stripping the percent signs produces something that looks right for ASCII and silently corrupts everything else. The second is decoding direction. atob returns a binary string, one character per byte, so decoding Chinese with atob and printing the result shows you mojibake; you have to pass those bytes through a UTF-8 decoder to get text back. The third is padding. Base64 without the trailing equals signs is accepted by some decoders and rejected by others, so the safe habit is to keep the padding - and to remember that the URL-safe variant of the alphabet swaps plus and slash for minus and underscore, and is used by JSON Web Tokens, where an unencoded plus sign in a query string would turn into a space.
Where you will actually meet it, and what it costs
Data URLs are the most visible use: they let you inline a small image or font in a stylesheet or a document, at the price of 33 percent more bytes and no way to compress it separately, plus browser and mail client limits on how long a data URL may be. Basic authentication is the second: a header containing Base64 of user:password, which is why it is only ever safe over HTTPS and why a server that accepts it over plain HTTP has told you it does not care about your password. JSON Web Tokens use Base64url for the header and payload, but the third segment is a binary signature, not an encoding of anything readable. Email attachments, historically, are Base64 wrapped at 76 characters per line. Storing binary inside a JSON field is a pattern worth avoiding rather than impossible. And one rule that is worth stating plainly: never put a Base64 string of a secret into a URL query string, because URLs get written into access logs, proxy logs, browser history and the referrer header of the next request.
Frequently asked questions
Is Base64 a way of encrypting data?
No. It is a reversible encoding with no key. Anyone can decode what this page produces in a second, with or without this page. If you need confidentiality, use actual encryption. If you need to prove integrity, use a hash. Use Base64 only when a format or a protocol requires it.
Will Chinese, Japanese or emoji text encode correctly?
Yes, because the text is converted to its UTF-8 byte sequence before encoding, which is what every real implementation does. A common shortcut - running the string through a Latin-1 encoder or through a percent-encoding trick - produces output that looks plausible and decodes to garbage, and that is the bug this tool is built to avoid.
Why does my decoded text look like gibberish?
Almost always an encoding mismatch. Base64 decodes to bytes, not to characters, and the bytes have to be interpreted as UTF-8 to become text. If the source was not UTF-8 - Latin-1, Shift-JIS, GBK - then you need to decode it with that encoding instead, and the result will never be recovered by guessing.
Is it free, and does it need an internet connection?
It is free, needs no account, and once the page has loaded the encoding runs locally, so a dropped connection does not interrupt it. Nothing you type is transmitted: there is no upload endpoint on this page, though the site does carry advertising, which can see page-level information such as your IP address.