Base64 Encoder / Decoder
Encode and decode Base64, Base64URL, Base32 and hex — text live as you type, files by drag and drop — with a decoder strict enough to tell you the exact position of the first character that does not belong, instead of a shrug. Everything runs in your browser: the strings people decode are so often tokens and secrets that sending them to a server, or pasting them into a logged AI chat, is the one thing a decoder must never ask you to do.
Files
Drop a file anywhere in this box to encode it with the format selected above — you get the encoded text and a ready-made data URL. Or paste encoded text here and download the decoded bytes as a file.
Four alphabets, one job
All four formats do the same thing — write arbitrary bytes using only safe, printable characters — for different audiences. Standard Base64 is the default of email attachments, config files and a thousand APIs. Base64URL swaps the two characters that would break a URL (+ and /) for - and _, drops the padding, and is the alphabet inside every JSON Web Token — decode one with the JWT decoder and all three segments are this format. Base32 uses a smaller, case-insensitive alphabet that survives being read aloud and retyped, which is why TOTP authenticator secrets are issued in it. Hex doubles the size and buys total transparency: one byte, two characters, nothing hidden — the format of hashes, which the hash generator produces and the hash identifier recognises.
The strictness is deliberate, and it is the difference between a decoder and a debugging tool. Browser built-ins like atob() throw a single generic error for a string with a typo at position 4 and a string that is not Base64 at all. This decoder validates character by character and reports the first position that fails — a quote dragged in from JSON, a + where the URL-safe alphabet belongs, padding stranded in the middle, a final character whose spare bits are non-zero, which means the string was edited after encoding. Ninety percent of "this won't decode" mysteries are visible at that one position once somebody points at it. And because the job so often involves credentials — a Kubernetes secret is Base64 (an encoding, never an encryption), a token payload, a key in a config file — the whole conversion happens locally, following the same rule as the .env validator: sensitive input is never transmitted. The companion article, Base64 is not encryption, is the longer argument for why that distinction matters.
Frequently asked questions
Is Base64 a form of encryption?
No. Base64 is an encoding — a reversible change of costume with no key and no secrecy. Anyone who sees a Base64 string can decode it instantly, which is why "the API key is Base64-encoded in the config" means the API key is effectively in the config in plain text. The article Base64 is not encryption untangles encoding, encryption and hashing, and the mistakes each confusion produces.
Why does this decoder tell me the exact position of an error?
Because "invalid character" with no position is how generic decoders waste your afternoon. Pasted strings usually fail for one of three reasons: a stray character from the surrounding text (a quote, a comma, a line of a log), the wrong alphabet (a URL-safe string fed to a standard decoder), or a truncated copy. Here the first offending character is named with its index, so you can look at that exact spot and see which of the three happened.
What is the difference between Base64 and Base64URL?
The alphabet. Standard Base64 uses + and /, which are structural characters in URLs, so URL-safe Base64 swaps them for - and _ and usually drops the = padding. That is the variant inside every JWT. Feeding one variant to the other decoder is the most common cause of a decode failure at the position of the first + or / — this tool keeps the modes separate so the error message can tell you that is what happened.
Is it safe to decode a token or a secret here?
Yes — the conversion runs in your browser, in this page, and nothing you paste is transmitted or stored. That matters, because the things people decode are so often credentials: a Base64 blob in a config file, a Kubernetes secret (which is Base64, not encryption — see the question above), the payload of a token. Pasting the same string into an AI chat sends a copy to a logged, third-party system; see never let a chatbot do your secrets.
Why did my file decode as "not valid UTF-8"?
Because it is binary — an image, an archive, a compiled anything — and binary is not text. The text decoder refuses rather than handing you mojibake. Use the file section below the text boxes: paste the Base64 there and download the reconstructed file with its bytes intact.