Why does a JWT use Base64url encoding rather than standard Base64, and why is padding dropped?

## The problem Base64url solves Base64 turns arbitrary bytes into text using 64 characters plus a padding character. The classic alphabet ends with `+` and `/`, and pads with `=`. All three are hostile in the places tokens travel: - `+` means a literal space in `application/x-www-form-urlencoded` data, so a token pasted into a query string silently corrupts. - `/` is a path separator; a token in a URL path segment or a filename would be split. - `=` is the name/value delimiter in query strings and cookie strings, and is reserved in URI syntax. Every one of those would force percent-encoding, meaning the same token has two textual forms depending on where it appears — an invitation for bugs at exactly the layer where security depends on comparing bytes. ## The substitution Base64url is the URL- and filename-safe alphabet defined alongside standard Base64: identical for the first 62 characters, with index 62 encoded as `-` instead of `+` and index 63 as `_` instead of `/`. Nothing else changes; the bit-packing is the same, so converting between the two forms is a two-character search-and-replace, which is exactly what shell one-liners do before calling a standard Base64 decoder. ## Why padding is dropped Base64 encodes three bytes into four characters. When the input length is not a multiple of three, the final group is short and standard Base64 appends one or two `=` characters so the output length is always a multiple of four. That padding is pure redundancy: the decoder can tell how many bytes the final group carries from how many characters are left. JOSE therefore **requires** that the padding be removed, and encoders that leave it on produce tokens some verifiers reject. The consequences are practical. A segment length of `4n+1` is invalid and signals a malformed token. And many standard library decoders — written for padded input — reject an unpadded segment, which is why JWT libraries ship a dedicated Base64url decoder and why hand-rolled decoding is a common source of "works in one language, fails in another" bugs. ## Why the dot works as a separator Once the alphabet is `A–Za–z0–9-_` with no padding, no segment can contain a `.`. That makes the dot an unambiguous delimiter: a parser can split first and decode later, and a malformed token is detected by counting segments rather than by decoding. It also means a JWT survives being logged, copied out of a terminal, put in a `Location` header of a redirect, or used as a cache key without any escaping step. ## Consequences for size Base64 of any flavour costs about 33% expansion: three bytes become four characters. Dropping padding saves at most two characters per segment — negligible, and not the reason it is dropped. If a token is too large for a header or a cookie, the fix is fewer or smaller claims, never a different encoding. It is worth being explicit about that in an interview, because "drop padding to save space" is a tempting but wrong rationale. ## What interviewers are checking This is a details question, and it separates people who have debugged tokens from people who have only consumed a library. The strong answer names the two substituted characters, states that JOSE mandates unpadded output, and connects both to where tokens actually travel. A weak answer says "it is a variant of Base64" and stops.