# encoding.base64
Base64 from RFC 4648: `base64Encode` / `base64Decode` use the standard
alphabet (`+`, `/`) with `=` padding, and `base64UrlEncode` /
`base64UrlDecode` use the URL- and filename-safe alphabet (`-`, `_`) of
section 5, without padding, which is the form JWTs (RFC 7515 section 2) and
most URL tokens use. The four ship as one group because the two alphabets
share one codec; install only what you call with `only=`.
Bytes are lists of integers 0 to 255, as everywhere in the registry (see
`encoding.hex`). Python callers can pass a `bytes` value directly.
**Decoding is strict.** Line breaks, spaces and characters outside the
alphabet are errors, not skipped (RFC 4648 section 3.3 says to reject them
unless a specification says otherwise). Standard base64 must be padded to a
multiple of four characters. The unused bits in the last character must be
zero: `"Zh=="` is refused even though a lenient decoder reads it as `"f"`,
because accepting it would give one byte string several spellings, which
matters when the text is compared or signed (section 3.5). The URL-safe
decoder accepts text with or without padding, but padding that is present has
to be right, and a length that no byte count produces (one character past a
multiple of four) is an error.
Mixing alphabets is an error in both directions: `+` or `/` in base64url text,
and `-` or `_` in standard base64 text. That is almost always a token pasted
into the wrong field.
Source: RFC 4648, The Base16, Base32, and Base64 Data Encodings, sections 4,
5, 3.3, 3.5, and the test vectors in section 10
(https://www.rfc-editor.org/rfc/rfc4648). The base64url example of a JWS
header is from RFC 7515 appendix A.1.