Base64 Encode and Decode

Some systems can only carry plain text. An email header, a data URL in a web page, a token in an API call, a value in a YAML or JSON config file: each of these expects letters and numbers, not raw bytes. Base64 solves that by rewriting any data using just sixty-four safe characters, so it can travel through a text-only path and come out the other side unchanged.

The trade is size. Every three bytes become four characters, so the output is about a third bigger than what you started with. That is the cost of safe passage, and it is why Base64 is used for small values like keys, tokens and tiny images rather than for large files.

Both directions sit on the same page, because you almost never need only one. Paste text, read the Base64 on the right, then tap Swap. The result moves into the left box and the direction flips, so you decode what you just encoded and see your original text come back. That is the quickest way to prove a value survived a copy and paste, which is where most Base64 problems actually start.

The counter under each box shows the character count and the size in bytes, so the one third growth is visible rather than something you have to take on trust.

Standard Base64 uses plus and slash as two of its sixty-four characters. Both cause trouble outside plain text. A slash separates parts of a web address, and a plus can be read as a space in a query string, so a token pasted into a link can arrive damaged. The URL-safe alphabet swaps those two for minus and underscore, which pass through links and filenames untouched.

Decoding accepts either alphabet without being told which one you used, so you can paste a token from a link and it just works. If you are working with query strings rather than data, the URL encoder and decoder is the tool you want instead.

Base64 works in groups of four characters. When your data does not divide evenly, one or two equals signs are added at the end to fill the last group. Turn off Keep padding and those are removed, which some APIs and JSON web tokens expect. Decoding here works either way, because the missing padding can be worked out from the length.

Line wrapping is the other old convention. Email and PEM certificate formats want short lines, traditionally sixty-four or seventy-six characters. Set Wrap every N characters to match whatever your target format asks for, or leave it at zero for one continuous line.

Nearly always because something came along for the ride. A quote or a bracket copied with the surrounding code, a stray character at the end, or text that was cut off partway through. Rather than failing with a vague complaint, this tool names the exact character that cannot appear in Base64, so you know what to delete. If the length itself is impossible, it says the text looks cut off instead, because that is a different problem with a different fix.

Spaces, tabs and line breaks are never a problem. They are ignored before decoding, so Base64 wrapped across many lines pastes in fine exactly as you found it.

Yes, and that is the point of building it this way. Many free Base64 sites send whatever you paste to their own server to do the work, which means your API key, session token or private note is now sitting in someone else's logs. This page does the conversion in your browser, so the text never leaves your device.

One honest warning that has nothing to do with this site: Base64 is not encryption. It is trivially reversible by anyone who sees it. Encoding a password does not protect it. If you need secrecy, encrypt first, then encode the encrypted result. For a wider look at what runs locally here, see the developer tools or convert structured data with XML to JSON.