Base64 turns arbitrary bytes into a string of 64 safe characters, so that data which was never meant to be text can travel through channels that only accept text. It was designed for email attachments in the 1990s and it is still everywhere: data URIs, JWTs, HTTP Basic auth headers, JSON payloads carrying binary blobs.
What the encoding actually does
The encoder reads your input three bytes at a time. Three bytes are 24 bits, which it re-slices into four groups of six bits. Six bits can hold 64 values, and each of those values maps to one character from the alphabet A–Z, a–z, 0–9, plus "+" and "/". That is the whole trick.
When the input length is not a multiple of three, the last group is short and the encoder pads the output with one or two "=" characters, so the result always divides evenly by four. That is why you see trailing equals signs on some strings and not others — it tells you the original length modulo 3, nothing more.
The 33% you pay for it
Four output characters for every three input bytes means Base64 output is about 33% larger than the input. A 900 KB image becomes roughly 1.2 MB of text. This matters most in the place people reach for Base64 most eagerly: inlining images as data URIs in CSS or HTML.
Inlining saves one HTTP request, which was worth a lot under HTTP/1.1 and is worth much less under HTTP/2 and HTTP/3, where requests are multiplexed. Meanwhile the cost is real: an inlined image cannot be cached separately from the document, so every change to the page re-downloads the image, and every visit re-downloads it with the HTML. As a rule of thumb, inlining is defensible for tiny assets — an icon of a few hundred bytes — and a mistake for photographs.
Base64 is not encryption
This is the single most common misunderstanding, and it causes real incidents. Base64 has no key. Anyone holding the string can decode it in one step, including in the browser you are reading this in. Encoding a password, an API token, or a customer record in Base64 protects nothing at all — it only makes the value unreadable to a human skimming a log file, which is not a security property.
A JWT makes this concrete. Its header and payload are Base64url, not encrypted: paste one into a decoder and you will read every claim inside. The signature stops someone from *changing* the token, not from *reading* it. Never put anything in a JWT payload that the token holder should not see.
The URL-safe variant
Standard Base64 uses "+" and "/", and both mean something else in a URL: "+" can be read as a space in a query string, and "/" is a path separator. The base64url variant defined in RFC 4648 §5 swaps them for "-" and "_", and usually drops the padding. If a token you are decoding contains "-" or "_" and no "=", you are almost certainly looking at base64url — which is what JWTs use.
Common questions
Does my data get sent to a server?
No. This tool is marked "client": the encoding runs in your browser tab using its own JavaScript engine, and your input never leaves the machine. Close the tab and nothing remains. That said, if the data is genuinely sensitive, use a tool your organisation controls rather than any free web page — including this one.
Why does my decoded text show strange characters?
Almost always a character-encoding mismatch. Base64 encodes bytes, not characters, so it cannot know whether those bytes were meant to be UTF-8, Latin-1 or something else. If the original text was UTF-8 and it is being interpreted as Latin-1, accented letters turn into pairs like "Ã ". The Base64 step is fine; the interpretation after it is not.
Why do JavaScript's btoa() and atob() break on accented characters?
Because they predate Unicode support and only handle characters in the 0–255 range. Passing "è" to btoa() throws an InvalidCharacterError. The modern fix is to convert to bytes first with TextEncoder, then encode those bytes — which is what this tool does for you.
Is there a size limit?
Not one imposed by the tool, but a practical one imposed by your device. Everything happens in memory, and the encoded copy is a third larger than the input, so very large files will make the tab sluggish before anything fails outright. For multi-megabyte binaries, a command-line tool is the better instrument.