Base64 decode that names what it found

Because something read the decoded bytes as Latin-1 when they are UTF-8. The browser's own atob() hands back one character per byte, so the pair C3 A9 that spells é surfaces as à followed by ©, and the four bytes of an emoji surface as ð plus three invisible control characters. This page never takes that shortcut: the bytes go through TextDecoder in UTF-8 mode, so é is é and 😀 is one emoji. When a byte run is not valid UTF-8 at all, you get a hex dump and a note saying so, rather than a page full of replacement characters.

Yes — that is base64url, the alternative alphabet in RFC 4648 §5, where - stands in for + and _ for /. It exists because + and / already mean something inside a URL and a filename: + is a space in a query string and / is a path separator, so a plain Base64 value pasted into a link arrives at the server mangled. This decoder spots either alphabet on its own and tells you which one it found. What it will not do is decode a string containing both, since one of the two markers must then be corruption and picking a winner would hand you wrong bytes with no warning.

Yes, and it is the common case for tokens and URLs. Padding carries no data — it only rounds the final group up to four characters, so a decoder can work out from the length alone that a 4n+2 string is short by two = and a 4n+3 string by one. This page adds them back silently and says it did. The one length that cannot be repaired is 4n+1: no combination of bytes produces a single leftover character, so that string lost something in transit.

It reads the first bytes of the decoded output and compares them against known file signatures. A PNG opens with 89 50 4E 47, a JPEG with FF D8 FF, a PDF with the literal %PDF-, a gzip stream with 1F 8B, a ZIP with 50 4B 03 04, and a WOFF2 font with the ASCII wOF2. Signatures are checked before any attempt at text, because a file whose bytes happen to be valid UTF-8 is still a file. Only when nothing matches does the decoder try UTF-8, and only then does it look at whether the text is JSON, markup or prose.

No, and nothing encoded in it is protected in any way. Base64 is a reversible transport encoding with no key and no secret: this page decodes it, so can every language's standard library, so can anyone who intercepts it. A password sitting in a Base64 header is a password in plain sight — HTTP Basic auth is exactly that, which is why it is only acceptable over TLS. If the output is still unreadable after decoding, you are holding ciphertext or a compressed stream rather than text; ciphertext has no recognisable structure, while gzip announces itself with 1F 8B and gets inflated here automatically.

It means the string cannot be the output of any Base64 encoder, because encoders emit characters in groups: 3 bytes make 4 characters, 2 bytes make 3, 1 byte makes 2. A remainder of exactly one character is unreachable. In practice something ate a character — a copy that stopped one short, a spreadsheet cell that trimmed the value, a log line cut at a column limit. The error names the length so you can compare it against the source rather than guessing.

Here, yes: a token with three dot-separated segments is recognised, and its header and payload are decoded from base64url and shown as indented JSON. Most decoders reject it, and correctly so — the dots are not Base64 characters, so a JWT is three Base64 strings rather than one. What no decoder can do is tell you whether the token is genuine, because verifying an HS256 or RS256 signature needs the key. Reading the claims and checking how long exp has left belongs on the JWT decoder page.