HuntsvilleEngineers mark

Base64/Hex Encoding Overhead

Size a payload after Base64, Base32, or hex encoding — exact RFC 4648 byte counts for link budgets, MTU checks, and storage estimates.

InputBase64: 4·⌈n/3⌉ Base64 unpadded: ⌈4n/3⌉ MIME: +2·⌈len/76⌉ for CRLF Base32: 8·⌈n/5⌉ Hex: 2n

Your recent runs (stored only in your browser)

No calculations yet — results land here so you can compare runs.

The engineering

Binary-to-text encodings buy you safe transit through text-only channels at the cost of size. Base64 maps every 3 raw bytes to 4 ASCII characters (~33% growth), Base32 maps 5 bytes to 8 characters (60% growth), and hex simply doubles everything. Use this card when you're checking whether an encoded blob fits a header limit, a UDP datagram, a QR code, a database column, or a data: URI budget.

The gotchas live at the edges: padded Base64 always rounds up to a multiple of 4 characters, so a 1-byte payload becomes 4 characters — 300% overhead, not 33%. MIME transfer encoding adds another ~2.7% for CRLF line breaks every 76 characters, and JSON-embedded Base64 picks up quoting and escaping on top of what this card computes. If your encoded size is coming out exactly 4/3 of raw with no remainder, your payload length happens to be a multiple of 3 — that's the only time padding is free.

Going the other way, raw size from a padded Base64 length is 3·len/4 minus the padding count — handy for pre-allocating decode buffers without touching the data.

Where this math comes from

Binary-to-text encoding is a child of email. Early ARPANET mail and UUCP links would mangle anything that wasn't 7-bit ASCII, so in 1980 Mary Ann Horton wrote uuencode at Berkeley — 3 bytes into 4 printable characters, the same arithmetic Base64 uses today, just with a clumsier alphabet that broke through EBCDIC gateways. The cleaned-up 64-character alphabet arrived in 1987 with RFC 989, the Privacy-Enhanced Mail spec, which needed encrypted binary to survive any mail relay on Earth.

MIME (RFC 2045, 1996) made Base64 ubiquitous by naming it a standard Content-Transfer-Encoding, complete with the 76-character line rule this card models. A decade later Simon Josefsson consolidated the scattered variants — Base64, Base64url, Base32, Base16 — into RFC 4648 (2006), the document that pins down the exact padding and alphabet rules every library implements now.

  1. 1980Mary Ann HortonWrites uuencode at Berkeley — the original 3-bytes-to-4-characters scheme for mailing binaries.
  2. 1987IETF / RFC 989 (PEM)Defines the modern 64-character alphabet with '=' padding for Privacy-Enhanced Mail.
  3. 1996Freed & Borenstein / RFC 2045MIME standardizes Base64 as a Content-Transfer-Encoding with 76-character line wrapping.
  4. 2006Simon Josefsson / RFC 4648Consolidates Base64, Base64url, Base32, and Base16 into the single reference spec used today.

See the full timeline of the math behind every calculator →

Runs entirely in your browser — nothing you enter leaves this page. Your recent runs are stored only on your device.