Base64 Decode

You have an opaque run of letters and digits — the middle segment of a JWT, a value out of a Kubernetes Secret, a chunk of an email header, a string in a log line — and you need to see what is inside it. Decoding it should take one paste. In practice it often does not, because the string arrived without padding, uses the URL-safe alphabet, or has line breaks in it from being wrapped at 76 characters somewhere along the way.

This decoder handles all of that. It accepts both RFC 4648 alphabets — standard +// and URL-safe -/_ — strips whitespace and line breaks, and restores missing padding automatically, so a bare JWT segment decodes without you having to append = characters by hand. Bytes are decoded as UTF-8 with TextDecoder, so accents, CJK text and emoji come back intact rather than as mojibake. When the input genuinely cannot be Base64, you get a specific reason instead of a blank pane.

Padding, alphabets and JWT segments

Base64 output is normally padded with = to a multiple of four characters. The padding carries no data — it exists so that concatenated Base64 blocks can be split apart again — and many producers omit it. JWTs omit it by specification.

A JWT is three URL-safe Base64 segments separated by dots: header.payload.signature. To inspect one, paste a single segment, not the whole token — the dots are not part of the Base64 alphabet and the segments are independent. The header decodes to something like {"alg":"HS256","typ":"JWT"}; the payload decodes to the claims. The signature segment is raw bytes, not text, so decoding it will produce the not-valid-UTF-8 warning; that is expected and not an error.

Because the padding is restored here automatically and both alphabets are accepted, you can paste a segment straight out of a token, an Authorization header or a browser cookie with no preparation.

Two things worth remembering about JWTs: decoding one shows you its contents but proves nothing about its authenticity — verifying the signature requires the key. And the payload is only encoded, never encrypted, so anything in a JWT claim is readable by anyone holding the token.

What the error messages mean

• "the length is impossible (4n+1 characters)" — Base64 encodes 3 bytes into 4 characters, so after padding is stripped the length can be a multiple of 4, or 2 or 3 more than one, but never exactly 1 more. A string of 5, 9 or 13 characters cannot be valid Base64. In practice this means a character was dropped or added during copying.
• "Invalid Base64 character: …" — the offending character is named in the message. The usual culprits are a space that was really a + before a form-decoder got to it, a stray quote or comma copied along with the value, an ellipsis where output was truncated, or the dots from a full JWT.
• "The decoded bytes are not valid UTF-8" — this is a warning, not a failure. The Base64 was fine; what came out simply is not text. You have decoded an image, a compressed archive, a cryptographic signature or some other binary payload, and the count of undecodable sequences is reported so you can see how far from text it is.

A space where a plus sign belongs deserves its own note, because it is the most common of all. If Base64 travels through a URL or a form field as standard Base64, the + characters get decoded as spaces at the far end. If your string has spaces scattered through it in otherwise plausible positions, replacing them with + will usually make it decode.

Where Base64 turns up, and what decoding does not tell you

• Kubernetes Secrets — every value under data: is Base64. This is a YAML encoding convenience, not protection; the values are not encrypted at rest by default.
• HTTP Basic auth — the header is Basic followed by Base64 of username:password. Decode it and you have the credentials in the clear, which is precisely why Basic auth is only acceptable over HTTPS.
• Data URIs — everything after base64, in a data: URL is the encoded resource.
• Email — MIME encodes attachments and non-ASCII headers in Base64, wrapped at 76 characters.
• PEM files — the body between the -----BEGIN----- and -----END----- lines is Base64-encoded DER. Decoding it yields binary, so expect the UTF-8 warning.

Decoding tells you what the bytes were. It tells you nothing about whether the data is trustworthy. Base64 is not signed, not encrypted and not tamper-evident: anyone can alter a Base64 string and re-encode it. Treat decoded content with exactly the same suspicion you would treat the source it came from.