Base64 decode online
Paste a Base64 string and read it back as text. Line breaks, stray spaces, the URL-safe alphabet and missing padding are all handled. When a string cannot be decoded you get the reason — which character is wrong and where, or that the bytes are binary rather than text.
Decoding happens inside this browser tab. Nothing you paste is uploaded to a server or stored anywhere — close the tab and it is gone.
How decoding works, and where it goes wrong
Decoding reverses the mapping the encoder applied. Each Base64 character contributes six bits, four characters rebuild three bytes, and the trailing = signs say how many of that final trio to keep. Before any of that happens, this page tidies the input: whitespace and line breaks are dropped, - and _ are translated back to + and /, and absent padding is restored from the length. That covers almost every string people paste — copied out of an email header, a log file, a JWT or a YAML block that folded the value across several lines.
After that, two different things can go wrong, and they need different fixes, so the tool reports them separately. Either the text is not Base64 in the first place, in which case you are told which character is unacceptable and its index in what you pasted; or the Base64 is perfectly valid but the bytes behind it are not UTF-8 text, in which case you are told how many bytes there are and shown the first 32 of them in hex.
That second distinction only exists because decoding uses TextDecoder in fatal mode. Left in its default mode, the decoder quietly substitutes a replacement character for every byte sequence it does not understand, and you get a screen of black diamonds that looks like a successful decode of corrupt data. Failing loudly is more useful: it tells you the string was never text to begin with.
Questions about decoding Base64
What does the index in the error message point at?
The position of the offending character in the text exactly as you pasted it, counting from zero and counting every space and line break along the way. So if the message names index 41, put the cursor at the start of the box and press the right arrow 41 times to land on it. The usual culprits are a stray quotation mark left over from a JSON file, a hyphen inserted by a mail client that wrapped the line, or a fragment of the surrounding key name that came along with the copy.
Do I need the equals signs at the end?
Not here. Padding exists so that a decoder reading a stream knows where one value stops, and its length is implied by the length of the rest: a Base64 string is always a multiple of four characters once padded, so a leftover of two characters needs two equals signs and a leftover of three needs one. This tool works that out for you. What it cannot repair is a leftover of one character, which no valid Base64 string ever has — that means characters are genuinely missing, and you get told so rather than being handed a plausible-looking wrong answer.
Why does it say my data is binary instead of showing text?
Because the bytes decoded successfully but do not form valid UTF-8. Every byte from 0x80 upwards is part of a multi-byte character in UTF-8 and has to appear in a specific pattern; a PNG header, an encrypted blob or a gzip stream breaks that pattern within a few bytes. The hex preview usually identifies what you have: 89 50 4e 47 is a PNG, ff d8 ff a JPEG, 25 50 44 46 a PDF, 1f 8b gzip. If you were expecting text, the likely cause is that the value was double-encoded or that you copied a binary field by mistake.
Can I decode a Base64 image or file here?
You can confirm what it is and how large it is, but this page deliberately does not offer the bytes back as a download. It is a text tool: it tells you the byte count and shows the first 32 bytes in hex so you can identify the format from its magic number. To view a Base64 image, paste it into your browser's address bar behind data:image/png;base64, and the browser will render it. To recover a file, use a command line: base64 -d file.txt > out.bin on macOS and Linux, or certutil -decode on Windows.
Is it safe to paste a token or a JWT in here?
The decoding itself never leaves your device — there is no upload, no logging and no storage, and you can confirm that in the Network panel of your developer tools. The wider question is whether a live credential should be pasted into any web page at all, and the honest answer is that it depends on how much you trust the page. For a JWT specifically, the middle segment is just claims and is safe enough to read, but the signature at the end is what makes the token usable. Treat an unexpired production token the way you would treat a password.