Base64 Encode / Decode

Base64 hides nothing at all

It gets mistaken for security because the output looks scrambled. It is not scrambled, it is re-spelled. The rule is fixed: take three bytes, split those twenty-four bits into four groups of six, and write each group as one character from a set of sixty-four — A–Z, a–z, 0–9, + and /. When the input does not divide evenly by three, = pads the output to a multiple of four characters. That is the whole specification, and it means Base64 output is always about a third larger than its input.

The clearest example of the confusion is HTTP Basic authentication, which sends the credential as Base64 of user:password. A header carrying ZGVtbzpub3QtYS1yZWFsLXBhc3N3b3Jk is carrying demo:not-a-real-password in plain view of anything on the wire. Basic auth is only safe over HTTPS, and the Base64 contributes nothing to that safety. It is there so the credential survives being put in a header, not to keep it quiet.

Encoding, hashing and encryption are three different jobs

These get used interchangeably in conversation and they are not interchangeable at all. Pick by the question you are actually trying to answer.

If you need the third row, use the text encryption tool, which derives an AES-GCM key from your passphrase with PBKDF2 rather than pretending an encoding is a lock. If you need the second, the hash generator does it through the browser's Web Crypto API. If you are here, you almost certainly need the first — and the first is a plumbing decision, not a security one.

Two characters, four steps

Encode Hi and you get SGk=. Follow it through, because once you have seen it once the padding stops being mysterious. H is byte 72, i is byte 105. Written as bits that is 01001000 01101001 — sixteen bits, which is not a multiple of six, so the last group is filled out with zeros: 010010, 000110, 1001+00. Those three groups are alphabet positions 18, 6 and 36, which are S, G and k. Three characters is not a multiple of four, so one = is added. Add one more input character — encode Hi! — and the padding disappears entirely, because three bytes fit four characters exactly.

Now try é. This tool returns w6k=, because it encodes the UTF-8 bytes of your text, which for é are two bytes rather than one. A naive encoder built directly on the browser's btoa function returns 6Q== instead, treating the character as a single Latin-1 byte, and throws an error outright on anything outside Latin-1 such as an emoji. If you have ever decoded a Base64 string and got é where an accent should be, you have met that bug from the other side. Encode with the same character set you decode with and it goes away.

Why your Base64 says "invalid input"

Three causes, in the order you should check them.

• It is Base64URL, not Base64. URLs and filenames cannot carry + and /, so a variant alphabet swaps them for - and _ and usually drops the = padding. This tool decodes the standard alphabet. Paste a segment of a JSON Web Token here and it will very likely refuse, because tokens use the URL-safe variant — use the JWT decoder, which converts the alphabet back before decoding. If you specifically need percent-encoding for a query string, that is a different scheme again and lives in the URL encoder.
• The string is truncated. A Base64 encoder always emits a length that is a multiple of four, padding included, and a string whose length divides by four with a remainder of one cannot be valid at all — the decoder rejects it outright. Copying out of a terminal that wrapped the line is the usual culprit. Line breaks inside the string are harmless and get stripped before decoding; a missing tail is not recoverable.
• It is not text. This tool decodes Base64 back into readable text. Hand it the Base64 of a PNG or a zip file and the decoded bytes are not valid text, so it reports invalid input rather than printing thousands of replacement characters. That is the right answer, not a limitation to work around — to go the other direction and turn a picture into a data URI, use image to Base64, which is built for binary.

The blob you are decoding is usually somebody's data

Nobody Base64-decodes poetry. The realistic case is an opaque string out of an API response, a config value from a deployment pipeline, or the contents of a Kubernetes secret — which are stored Base64-encoded and are routinely mistaken for encrypted. In other words, the exact material that should never be typed into an unknown website. A remote decoder receives the plaintext of everything you paste, keeps whatever logs it keeps, and owes you nothing.

This page does the conversion with two lines of JavaScript already running in your tab. There is no fetch call, no XMLHttpRequest and no beacon in the script; it is the browser's own btoa and atob with a UTF-8 step wrapped around them. Turn off your network and the tool behaves exactly as it does now — the simplest proof available that nothing was leaving. The rest of the set works the same way; see the full tool index.