The Base16, Base32, and Base64 Data Encodings
obsoletes
- rfc-3548 — The Base16, Base32, and Base64 Data Encodings
Extracted elements (27)
Base16 requires no padding because each input octet maps to exactly 2 output characters with no leftover bits, unlike base64 (6 bits/char from 8-bit input) and base32 (5 bits/char from 8-bit input) which can leave unused bits in the final quantum.
Base32hex uses the alphabet 0–9 followed by A–V specifically because this preserves sort order when encoded data is compared bit-wise, a property the standard base64 and base32 alphabets lack. This is required for DNSSEC NSEC3 authenticated denial of existence.
The base32 alphabet omits '0' (zero) and '1' (one) to reduce human transcription errors, since '0'/'O' and '1'/'l'/'I' are easily confused. A lenient decoder may map '0' to 'O' and '1' to 'I' or 'L', but MUST NOT do so by default.
The URL-safe base64 alphabet uses '-' and '_' at positions 62 and 63 (replacing '+' and '/') because '/' is problematic in file names and URLs, '~' has special meaning in some file system environments, and '.' is undesirable when multiple dots are disallowed in filenames.
MIME enforces a 76-character line length limit on base64 data, inherited from PEM (which uses 64 characters), both originating from SMTP constraints. RFC 4648 does not impose line length limits; applications referencing RFC 4648 must explicitly specify if line wrapping is required.
RFC 4648 obsoletes RFC 3548, adding the base32 extended hex alphabet, referencing IMAP for its specialized base64 variant, adding test vectors, and adding a security consideration about cryptanalytic signatures.
The 'base32hex' encoding MUST NOT be referred to simply as 'base32' and should not be treated as equivalent to it; they use different alphabets and encoded data is not interchangeable.
The 'base64url' encoding MUST NOT be referred to simply as 'base64' and should not be treated as equivalent to it. Unless clarified otherwise, 'base64' means the standard alphabet with '+' and '/' at positions 62–63.
Decoders MAY choose to reject a base encoding if the pad bits have not been set to zero, enabling strict canonical enforcement. The referring specification may mandate a specific behavior.
Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise.
Implementations MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs base encoders to add line feeds after a specific number of characters.
Implementations MUST reject the encoded data if it contains characters outside the base alphabet when interpreting base-encoded data, unless the specification referring to this document explicitly states otherwise.
Pad bits in canonical base 64 and base 32 encoding MUST be set to zero by conforming encoders. Without this, multiple base-encoded strings can decode to the same binary data, and canonical encoding is not guaranteed.
Base 16 encoding ('base16' or 'hex') uses a 16-character US-ASCII subset of digits 0–9 and uppercase letters A–F. It represents 8-bit input groups as 2 encoded output characters (4 bits per character) and requires no padding.
Base 32 encoding ('base32') uses a 33-character US-ASCII subset of uppercase letters A–Z and digits 2–7 plus pad '='. It represents 40-bit input groups as 8 encoded output characters, encoding 5 bits per character, and is case insensitive.
Base 32 encoding with extended hex alphabet ('base32hex') uses the alphabet 0–9 and A–V plus pad '='. Unlike standard base32 and base64, encoded data maintains its sort order when compared bit-wise. Used by NSEC3 in DNSSEC.
Base 64 encoding ('base64') uses a 65-character US-ASCII subset (A–Z, a–z, 0–9, '+', '/', and pad '='). It represents 24-bit input groups as 4 encoded output characters, encoding 6 bits per character.
Base 64 encoding with URL and filename safe alphabet ('base64url') is identical to base64 except positions 62 and 63 use '-' (minus) and '_' (underline) instead of '+' and '/', avoiding characters problematic in URIs and filenames.
Base encoding implementations must guard against buffer overflow attacks and must not break on invalid input including embedded NUL characters (ASCII 0). Decoders should treat all out-of-alphabet input robustly.
Base encoding increases the amount of available plaintext and introduces a characteristic probability distribution, providing a signature useful for cryptanalysis. It should not be mistaken for encryption or obfuscation.
Base encoding provides no computational confidentiality and does not add entropy to the plaintext. It has caused security incidents where users inadvertently revealed passwords embedded in base64-encoded protocol traces, incorrectly believing the encoding protected the data.
If non-alphabet characters are ignored rather than rejected, a covert channel is created allowing information to be leaked. Ignored non-alphabet characters can also be used to bypass string equality comparisons or to trigger implementation bugs. Similarly, case variation in base16/base32 can leak information.
Non-significant pad bits may be abused to leak information, bypass string equality comparisons, or trigger implementation problems. Conforming encoders must set pad bits to zero; decoders may optionally reject encodings where they are not.
Base16 encodes each octet into 2 hex characters by splitting the 8-bit input into two 4-bit groups, each used as an index into the 16-character alphabet. No padding character is used because a full code word is always available.
Base32 bit ordering requires the input bit stream to be treated as most-significant-bit first: the first bit in the stream is the high-order bit of the first 8-bit byte.
Base32 encodes 5 octets (40 bits) into 8 characters. Partial final quanta of 8, 16, 24, or 32 bits produce 2+6=, 4+4=, 5+3=, or 7+1= character/padding combinations respectively.
Base64 encodes 3 octets (24 bits) into 4 characters. If the final quantum is 8 bits, output is 2 characters followed by '=='; if 16 bits, output is 3 characters followed by '='; if a multiple of 24 bits, no padding is needed.