How do you decode a base64.urlsafe_b64encode token whose '=' padding was stripped?

### What "URL-safe" actually changes Standard Base64 uses `A-Z a-z 0-9 + /`. Two of those symbols are hostile in a URL: `/` is the path separator, and `+` means a literal space when a query string is form-decoded. `base64.urlsafe_b64encode` substitutes `-` for `+` and `_` for `/` and changes nothing else — it is exactly `base64.b64encode(data, altchars=b"-_")`, and `urlsafe_b64decode` translates the pair back before decoding. What it does **not** do is drop the padding. `base64.urlsafe_b64encode(b"any carnal pleas")` returns `b'YW55IGNhcm5hbCBwbGVhcw=='`, trailing `=` and all, and `=` is itself awkward in a URL — it is the separator inside a query string and gets percent-encoded as `%3D` in many contexts. That is why the token formats you meet in the wild strip it, and why the interview question is about putting it back. ### The padding rule, derived Base64 consumes three input bytes at a time and emits four characters. When the input length is not a multiple of three there is a leftover group of one or two bytes: one byte becomes two characters plus `==`, two bytes become three characters plus `=`. So the encoded length is always `4 * ceil(n / 3)`, and `len % 4` of a stripped token can only be 0, 2 or 3 — never 1, because one leftover Base64 character carries six bits and cannot encode a whole byte. That gives the restoration formula directly: ```python padded = s + "=" * (-len(s) % 4) ``` Python's `%` returns a non-negative result for a positive modulus, so `-len(s) % 4` is exactly the number of characters missing to reach the next multiple of four: 0, 1 or 2 (and 3 only for the impossible `len % 4 == 1` case, which will fail the decode anyway, as it should). Writing `len(s) % 4` instead is the common off-by-one — it computes how many characters are *past* the boundary, not how many are missing. The deeper point is that the padding is redundant. The decoder can derive the leftover-byte count from the length alone; `=` exists so that concatenated Base64 streams can be split at message boundaries by a decoder that reads forward without knowing lengths in advance. In a JSON field or a URL segment you already know where the token ends, so stripping is lossless — and if your protocol strips, it must document that, because `binascii` will not guess. ### The silent-corruption trap The worst failure here is not the exception, it is the absence of one. `base64.b64decode` defaults to `validate=False`, which **discards every character outside the standard alphabet before decoding**. Feed it a URL-safe token and the `-` and `_` characters simply vanish: ```pycon >>> base64.b64decode("----") b'' >>> base64.b64decode("----", validate=True) binascii.Error: Only base64 data is allowed ``` Four valid URL-safe characters decode to nothing at all, with no error. In a real token the surviving characters usually still form a length that is not a multiple of four, so you often get `Incorrect padding` instead — but not always, and "sometimes an exception, sometimes wrong bytes" is the worst possible failure mode. Passing `validate=True` turns the whole class into a loud `binascii.Error`, and it costs one keyword argument. Use the matching function for the alphabet, and validate when the input is untrusted. ### Which exception, and why it matters All of these raise `binascii.Error`, which is a subclass of `ValueError` — so `except ValueError` catches padding and alphabet problems together if you would rather not import `binascii` to write the handler. The messages you will actually see are `Incorrect padding` (length not a multiple of four), `Only base64 data is allowed` (a non-alphabet character under `validate=True`), and `Invalid base64-encoded string` (a final group of exactly one character). Since Python 3.11 the lower-level `binascii.a2b_base64` also takes `strict_mode=True`, which additionally rejects data appearing after the padding — useful when you are parsing a concatenated stream rather than a single field. ### The rule to carry away Pick one convention per protocol and enforce it at the edge: URL-safe alphabet, padding stripped, restored with `-len(s) % 4` on the way in, decoded with `urlsafe_b64decode` and `validate=True`. Two functions that differ in two characters, one of which fails silently against the other's output, is exactly the kind of pairing that produces a bug report months later from one client on one code path.