Base64 decoder
Processed in your browser · nothing is uploaded
Decodes Base64 back to text, accepting the URL-safe alphabet and restoring padding that has been stripped. The two things that make a decoder reject perfectly valid input.
How to use the base64 decoder
Padding is the usual reason a decoder refuses input it should accept. The = characters exist to bring the length to a multiple of four, and many systems strip them because they are redundant. JWTs always do. A decoder insisting on them fails on good data. This restores them instead.
Only two things are actually refused here: a character that belongs to neither alphabet, and a length that leaves a remainder of one when divided by four, which no Base64 string can have. Everything else decodes. That is worth sitting with, because it means a truncated string whose length happens to land on a multiple of four decodes perfectly happily into the wrong bytes, with nothing to warn you. "It decoded" is not evidence the input was complete.
The other common surprise is decoding something that was never text. Base64 encodes bytes, so an encoded PNG decodes to bytes that are not valid UTF-8, and those arrive as replacement characters; the black diamonds; rather than as an error, because nothing about the Base64 was invalid.
If the string will not behave, check what you actually have. Three dot-separated parts is a JWT, and the JWT decoder splits and reads it properly. Percent signs followed by hex pairs is URL encoding, which is a different scheme entirely.
Questions
Usually stripped padding or the URL-safe alphabet. Both are accepted here.
Padding, to make the length a multiple of four. Many systems drop them, JWT included.
Only a character outside both alphabets, or a length one more than a multiple of four. Everything else decodes: a truncated string included.
Because it was not text. Base64 encodes bytes, so an encoded image decodes to binary, not to an error.
Those are replacement characters: the decoded bytes are not valid UTF-8. It is a correct decode of the wrong kind of data.
Strip the `data:image/png;base64,` prefix first and decode what follows.
No.