Base64 vs Hex Encoding: Size, Byte Boundaries, and Protocol Rules

An API returns a 32-byte digest as 64 hexadecimal characters. Another endpoint represents the same digest using 44 Base64 characters. The strings look unrelated, but decoding them can produce exactly the same bytes. Before comparing the values, the receiving application needs to know which representation each endpoint uses.

Base64 and hex both represent binary data as text. Base64 generally needs fewer characters for larger values, while hex makes byte boundaries easier to inspect. Choosing between them also involves the surrounding protocol: alphabet, padding, line breaks, case, length limits, and validation rules. Those details determine whether two systems exchange the intended bytes reliably.

Begin With Bytes and a Defined Representation

A byte contains eight bits and can represent a value from 0 to 255. Arbitrary bytes are not necessarily valid UTF-8 text or printable characters. Passing them through an interface that expects text can produce decoding errors, control characters, or transformations that change the data.

Binary-to-text encoding maps those bytes into a restricted character alphabet. The receiver applies the inverse mapping. This is different from deciding how human text becomes bytes: the word Hello can be encoded as UTF-8 bytes, then those bytes can be represented using hex or Base64.

For this ASCII example, the five bytes have hexadecimal values 48 65 6C 6C 6F. Their contiguous hex representation is 48656C6C6F, and their standard Base64 representation is SGVsbG8=. Decoding either representation returns the original five bytes. Interpreting those bytes as UTF-8 then produces the word.

Two representations of the same five bytes

The distinction matters when an application accidentally encodes the text 48656C6C6F instead of first decoding it as hex. That operation produces a representation of ten ASCII characters, not the original five-byte value. Identify the input type before applying another conversion.

Character counts can also differ from byte counts. The character é occupies two bytes in UTF-8, with hex representation C3A9 and Base64 representation w6k=. A size calculation based on the number of displayed letters would therefore be wrong. Agree on the original character encoding when converting human text, and apply binary-to-text encoding to the resulting bytes. Decoding Base64 alone does not tell the receiver which character encoding those bytes use.

Hex Maps Each Byte to Two Digits

Hexadecimal uses sixteen digits, conventionally 0–9 and A–F. Each digit represents four bits, so two digits represent one byte. In DEADBEEF, the byte boundaries are DE AD BE EF. A person examining a packet or memory dump can locate a particular byte directly.

For an input of n bytes, contiguous byte-oriented hex requires exactly 2 × n characters. This excludes display additions such as spaces, a 0x prefix, offsets, or line breaks. A formatted diagnostic dump is therefore larger than the minimal hex encoding.

Case rules belong to the format. RFC Base16 uses an uppercase alphabet, while many tools display lowercase hex or accept both. Do not assume that arbitrary case is acceptable in every protocol or that changing case is harmless when a signature covers the exact text.

Hex notation for an integer is related but not identical to a byte string. An integer display such as 0xA may omit leading zeros. A one-byte encoding normally requires two digits, such as 0A. Byte order becomes relevant when interpreting multiple bytes as a number; hex encoding itself preserves the byte sequence rather than choosing an integer endianness.

Base64 Packs Three Bytes Into Four Characters

Standard Base64 uses uppercase letters, lowercase letters, digits, +, and /. Each alphabet character carries six bits. Three bytes contain 24 bits, which fit into four six-bit groups. The encoding crosses byte boundaries, making it less convenient for locating a single changed byte visually.

When the input does not fill a final three-byte group, standard padded Base64 uses = at the end. This padding is separate from the 64-symbol data alphabet. For example, the one-byte value representing f becomes Zg==, while the two-byte value representing fo becomes Zm8=.

RFC 4648 specifies Base16, Base64, and the URL-safe Base64 variant, including rules for padding, non-alphabet characters, and canonical encoding. The protocol using an encoding can define particular allowances. A sender and receiver need agreement on those rules, not merely the label “Base64.”

For padded Base64 without line breaks, the output length is 4 × ceil(n / 3) characters. The approximate one-third expansion applies as the input grows; it is not an exact overhead for every short value. Encoding one byte as four characters is proportionally much more expensive.

Compare Exact Sizes for the Value You Have

Both encodings use ASCII characters, so their minimal representations occupy one byte per character in UTF-8. Other string-storage formats can have different memory costs. Transport escaping, framing, line breaks, and compression can also change the final payload size.

For 300 bytes, Base64 uses 200 fewer characters than hex, while adding 100 characters compared with raw binary. A 32-byte SHA-256 digest needs 64 hex characters or 44 padded Base64 characters. Changing the representation does not change the digest algorithm or the underlying result.

The checksum article explains the separate question of detecting changes in data. A digest displayed in hex is not inherently stronger than the same digest displayed in Base64. The security and integrity properties come from the algorithm and how the result is obtained and verified.

Follow the Transport’s Base64 Variant

Base64url substitutes - and _ for the standard + and / characters. Padding may be omitted when the enclosing specification permits or requires it. URL-safe does not mean that every surrounding URL, cookie, or form format can be ignored; the enclosing syntax still applies.

For example, + can be interpreted as a space by form-style query decoding. Passing a standard Base64 value through that path without the appropriate encoding can corrupt it before the Base64 decoder sees it. A raw string that works in JSON may therefore fail when copied into a query parameter.

Email adds another convention. MIME’s Base64 transfer encoding wraps encoded lines to a defined limit. RFC 4648 does not generally instruct encoders to insert line breaks unless the referring specification requires them. A MIME encoder and a compact token encoder can therefore produce different text for the same bytes.

Document the exact contract: variant, padding policy, whitespace policy, and expected decoded length. Do not make a decoder guess among several formats unless that compatibility behaviour is deliberate and tested. Guessing can conceal malformed input or make different services interpret one value differently.

Validate Decoding and Bound Resource Use

A successful conversion should establish that the input complies with the intended format and that the decoded bytes meet application requirements. For a fixed-size digest, check the decoded length. For an uploaded file, enforce a size limit and validate its content independently of the encoding.

Decoder defaults vary. Python’s base64 module documentation describes how the validate option changes treatment of non-alphabet characters in b64decode. Choosing strict validation should be an explicit implementation decision rather than an assumption about every library’s behaviour.

import base64

raw = b"Hello"
hex_text = raw.hex()
base64_text = base64.b64encode(raw).decode("ascii")
assert bytes.fromhex(hex_text) == raw
assert base64.b64decode(base64_text, validate=True) == raw

That example does not impose one universal whitespace policy: Python’s hex decoder has its own accepted syntax. If an interface requires contiguous canonical hex, validate that contract as well. Library acceptance and protocol acceptance are different requirements.

Limit encoded input before allocating large buffers, and enforce decoded limits too. An apparently harmless text field can carry a substantial binary object. Repeatedly decoding nested representations or retaining both forms in logs can increase resource use without adding value.

Encoding Does Not Provide Secrecy or Authenticity

Neither Base64 nor hex requires a secret key. Anyone with the representation can decode it. Credentials, personal information, and encrypted payloads may all appear in these formats, so an unreadable-looking value should not automatically be treated as safe to publish or log.

Encryption addresses confidentiality under its stated assumptions; an appropriate authentication mechanism addresses unauthorised modification. Encoding can carry the resulting bytes through a text interface, but it does not supply those protections itself. The data-protection guide considers the surrounding access, key-management, and retention controls.

Also establish whether comparisons concern bytes or text. If a protocol signs the exact encoded string, normalising case, padding, or whitespace can invalidate the signature. If it compares decoded values, canonicalisation and validation still need consistent rules. Do not accept alternative text forms merely because one decoder happens to produce the expected bytes.

Choose the protocol’s required encoding first. Where the choice is yours, Base64 can reduce text size, while hex supports inspection of byte-oriented values. Preserve the underlying bytes, specify the variant, and test the boundaries through the actual transport. Those decisions make the format dependable rather than just familiar.