Hex and Base16 are the same number system
There's no mathematical difference between "hex" and "Base16" — both describe the same base-16 positional system with the same sixteen digits, 0 through 9 and A through F. The distinction that matters in practice is formatting convention, not arithmetic. "Hex" is the informal, everyday name developers use in conversation and in ad-hoc code, usually written with a language-specific prefix like0x in C-family languages or &h in older BASIC dialects. "Base16" is the formal name used in specifications that need to be precise about encoding, most notablyRFC 4648, which defines Base16 alongside Base32 and Base64 as one of three standard binary-to-text encodings, all sharing the same design goal of representing raw bytes as printable characters.
Why RFC 4648 bothers to define something so simple
Base32 and Base64 need a specification because there are real design choices involved — which alphabet to use, how to handle padding, how to group bits. Base16 barely needs one: every byte becomes exactly two characters, using the sixteen-character alphabet everyone already recognizes as hex digits, with no padding ambiguity because every byte always produces exactly two output characters. RFC 4648 defines it anyway so that systems following the Base16/Base32/Base64 family of encodings can specify "Base16" as a named, interchangeable option — for example, in configuration formats or APIs that let a caller choose an encoding by name — without having to separately special-case hex as something different from its sibling encodings.
Case sensitivity and canonical form
RFC 4648's Base16 alphabet is defined as uppercase only (0–9, A–F), making it stricter than casual hex notation, which is used interchangeably in upper or lower case. Systems that describe themselves as strictly RFC-4648-compliant may reject lowercase input even though the numeric value is identical — this is a formatting rule, not a mathematical one. This tool is lenient in the direction from hex to Base16 (accepting either case and normalizing to uppercase) and produces uppercase output to match the RFC's canonical form, since that's the safest default when the output might be checked against a strict parser elsewhere.
When the distinction actually matters
In day-to-day development, writing 0xFF versus writing the bare canonical stringFF makes no difference to a compiler or a human reader — context makes it obvious both represent the same hex byte. The distinction becomes practically relevant only when working with a system, library, or protocol that explicitly names its encoding as "Base16" and specifies exact formatting rules (case, no separators, no prefix) as part of a contract — for instance, an API that accepts a encoding: base16 parameter alongside base32 and base64options, where matching the expected format exactly avoids a parsing error. Outside of that kind of formal interface, "hex" and "Base16" can be treated as interchangeable names for the same thing.
Base16 in hash digests
One of the most common places Base16 appears by name, even if nobody calls it that in conversation, is cryptographic hash output. Functions like MD5 and SHA-256 produce a fixed-length sequence of raw bytes — 16 bytes for MD5, 32 for SHA-256 — and those raw bytes aren't printable or easy to compare visually, so they're almost universally displayed as a lowercase Base16 string instead: a SHA-256 digest becomes 64 hex characters, an MD5 digest 32. Most hashing libraries expose a method like .hexdigest()specifically for this conversion, and the convention of lowercase (rather than the RFC's uppercase) is near-universal in this context, even though both are valid Base16 representations of the same bytes.
Formatting differences to watch for
Beyond case, the other formatting variable is the presence of a prefix or separator. A hex literal in code typically carries a language-specific prefix (0x, 0h, # for colors) or none at all if the context already implies hex, as in a hash digest. Canonical Base16 per RFC 4648 has no prefix and no separators between byte pairs — just a continuous string of hex digits. Some tools also insert spaces or colons between byte pairs for readability (as in a MAC address like3A:1F:0B), which is a display convention layered on top of Base16, not part of the encoding itself; stripping the separators recovers the canonical form.