base64 vs hex Encode/Decode Throughput Lab

Intro — what this post promises

APIs love base64. Debuggers love hex. Both inflate payloads and burn CPU. How fast is each direction in CPython, and what do you pay in size?

This is a hands-on lab with measured numbers:

1. Encode 32 MiB os.urandom with base64.b64encode, binascii.b2a_base64, binascii.hexlify, bytes.hex.
2. Decode the matching forms (b64decode, unhexlify, bytes.fromhex, …).
3. Expansion ratios (1.333× vs 2.0×).
4. Warm rebench after a colder first pass.

Related links:

• SHA-256 vs BLAKE2b vs xxHash localhost lab
• json vs orjson vs msgpack localhost lab
• zstd vs gzip vs lz4 compression localhost lab
• fsync vs fdatasync localhost lab
• Why your average latency graph is lying (p50 / p95 / p99)

Lab honesty (1 Oct 2026 IST): Shared Linux lab box (8 cores). Python 3.13.5. Affiliates: 0. MB/s uses raw bytes as the denominator for both encode and decode so codecs compare fairly.

Verdict up front: warmed encode is a dead heat — hexlify ~668 MB/s vs b64encode ~645 MB/s. Decode is where hex wins hard (unhexlify ~881 vs b64decode ~388 MB/s). Hex still costs 2.0× size vs base64 1.333×.

What we compared

Related links:

• SHA-256 vs BLAKE2b vs xxHash localhost lab

Lab topology

32 MiB os.urandom → encode → decode → assert round-trip
Metric: p50 wall; MB/s = 32 MiB raw / p50_s
Lead table: rebench n=15 after warmup (first pass noted)

Script: lab-evidence/40-base64-vs-hex/results/run_lab.py.

Lead table — rebench n=15 (p50)

Encoded sizes on this buffer: base64 44 739 244 bytes (1.333×); hex 67 108 864 (2.000×).

Related links:

• Why your average latency graph is lying (p50 / p95 / p99)

First-pass vs warm (honest)

The initial matrix saw b64encode at ~469 MB/s before later stability settled ~626–635 MB/s and rebench ~645 MB/s. Hexlify stayed ~640–670 across passes. Quote the warmed encode numbers; mention the cold first sample so nobody thinks we hid variance.

Other first-pass notes: b64encode→str via .decode("ascii") fell to ~340 MB/s; urlsafe_b64encode ~331 MB/s encode / ~247 MB/s decode on that pass — URL-safe is not free.

How to read these numbers

• Wire size: base64 wins (4/3 vs 2×).
• CPU decode: hex/unhexlify won big here.
• CPU encode: essentially tied once warm.
• bytes.hex ≈ hexlify for speed; type differs (str vs bytes).

Related links:

• json vs orjson vs msgpack localhost lab
• zstd vs gzip vs lz4 compression localhost lab
• SQLite WAL vs DELETE journal localhost lab

Pitfalls we hit (or avoided)

1. Denominator games — always MB/s on raw length.
2. One cold base64 sample — rebench/stability required.
3. Forgetting expansion when declaring hex “faster.”
4. URL-safe / str decode paths adding tax.
5. Compressing afterward — hex+zstd may still lose to base64+zstd; measure (compression lab).

Practical checklist

• Prefer base64 (or raw binary) on the wire when size matters.
• Prefer hex for logs/debug when humans read dumps.
• Avoid encode→str extras unless required.
• Benchmark both directions on your payload class.
• Pair with compression if blobs are large.

Bottom line: hex is not “slow base64” on this box — it is slightly faster to encode when warm and much faster to decode, at a 50% larger ASCII footprint than base64’s 33% overhead.

Related links:

• fsync vs fdatasync localhost lab
• posix fadvise sequential vs random localhost lab
• python re vs str methods localhost lab
• uuid4 vs secrets token localhost lab

Methodology footnote

Input: os.urandom(32 MiB). Timed with time.perf_counter. Decode arms assert equality to the original buffer. Expansion recorded from encoded lengths. Rebench used 3 warmups + 15 timed calls for the headline table.

Versions pinned

• Python 3.13.5 stdlib base64 / binascii
• Buffer 32 MiB (lab box MemAvailable was tight)

Size vs speed — a worked example

Take 32 MiB of raw API payloads you insist on ASCII-armoring:

• Base64 on the wire ≈ 42.7 MiB (1.333×) at ~645 MB/s encode → ~50 ms CPU on this box.
• Hex on the wire ≈ 64 MiB (2.0×) at ~668 MB/s encode → ~48 ms CPU.

Encode CPU is a wash; you just shipped ~21 MiB extra with hex. On decode, hex’s ~881 MB/s vs base64’s ~388 MB/s saves wall time if decode-bound — still check whether bandwidth or storage dominates. If you gzip/zstd afterward, re-bench the pair (hex often compresses differently than base64’s restricted alphabet).

When base64 still wins product-wise

JSON APIs, data URLs, and PEM-adjacent ecosystems expect base64. Hex shines in hexdumps, digests display, and some log pipelines. Do not switch encodings for a 3 MB/s encode delta; switch for ecosystem fit and size, then confirm decode path cost.

Append: encode RPS view

For a fixed 32 MiB buffer, encode p50 times imply whole-buffer rates:

Per-megabyte, that is the MB/s table again — useful when capacity planning says “N bulk exports/minute.” If your objects are 2 KiB JSON blobs instead of 32 MiB, fixed overheads loom larger; microbench large buffers to stress the codec, then confirm on production sizes (same advice as the orjson lab).

Also recorded on the first pass: binascii.b2a_hex 668 MB/s (alias family of hexlify) and standard_b64encode matching b64encode. Prefer the readable API; optimize only if profiles say so.

If you stream encode in chunks, expect different absolute MB/s but similar rankings; this lab is whole-buffer for clarity.

Related reading on this blog

The hash and compression labs sit next to this one in a “bytes on the CPU” cluster: hash if you need integrity, compress if you need size, base64/hex if you need ASCII safety. Measure the pipeline you ship, not each stage in isolation only.

Verdict

Warmed hexlify (~668 MB/s) and b64encode (~645 MB/s) are peers on encode; unhexlify (~881 MB/s) crushes b64decode (~388 MB/s). Pay 2.0× bytes for hex vs 1.333× for base64. Pick the encoding for the bottleneck you actually have — size, decode CPU, or human readability.

Evidence path on the lab box: lab-evidence/40-base64-vs-hex/results/. Affiliates: 0.