Base Encoding Size Calculator (Text/Data Bloat)

Inspectable records

Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Area

Computing & Information

Tranche

tranche-5

Evidence ID

t5-026

Ledger rows

1

No ledger note is attached.

Review findings

The Base64, Base32, and hex concepts are standard, but the listed percentage formulas are only approximate for Base64 and Base32, and URL-encoding is under-specified. Add exact size formulas, URL-encoding convention and content/frequency inputs, zero-length handling, and an honest estimate label before release.

Formula and scope findings

• Base64 overhead is approximately 33% only for large inputs; the exact encoded size is 4 × ceil(raw_bytes / 3), including padding, so overhead varies substantially for small inputs.
• Base32 overhead is approximately 60% only asymptotically; the exact padded size is 8 × ceil(raw_bytes / 5), so overhead varies with input length.
• Hex encoding is correctly characterized as 2 bytes per input byte and therefore 100% overhead, assuming one encoded character occupies one byte.
• URL-encoding has no single overhead formula based only on raw byte size. For ASCII-like input, each unescaped byte occupies 1 byte and each percent-encoded byte occupies 3 bytes; UTF-8 conversion, spaces, plus-sign handling, and URL-encoding conventions must be specified.
• The declared inputs omit the information required for URL-encoding estimates: reserved-character frequency or the actual byte content, plus the encoding convention.

Unit assumptions

• Raw size is measured in bytes, not Unicode characters or language-level string length.
• Encoded size is measured in ASCII/UTF-8 bytes; Base64, Base32, and hexadecimal output characters each occupy one byte.
• Base64 uses the standard RFC 4648 alphabet with '=' padding and no line wrapping.
• Base32 uses the standard RFC 4648 alphabet with '=' padding and no line wrapping.
• Hex uses two ASCII hexadecimal characters per input byte.
• URL-encoding assumes byte-oriented percent encoding where an unescaped byte costs 1 byte and an escaped byte costs 3 bytes; no form-urlencoded space-to-plus conversion is applied.

Boundary hardening

BREAK_CLAIMED · SELF_FLAGGED

Zero-byte input produces an undefined overhead percentage, and URL-encoding output depends on an unstated reserved-character convention. The calculator also has no safe numeric behavior for extreme magnitudes: for raw_byte_size = 1.7e308, the Base64 estimate 4 * ceil(1.7e308/3) is approximately 2.2666666666666668e308, which overflows JavaScript Number to Infinity; the input should be rejected as non-integral and out of range.

Errata and corrections

No applied erratum is attached to this unique-name record.

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "inputs": {
    "raw_byte_size": 1,
    "encoding_scheme": "Base64"
  },
  "expected_outputs": {
    "encoded_size_bytes": 4,
    "overhead_percent": 300
  },
  "working": "1. Number of Base64 groups = ceil(1 / 3) = 1. 2. Each group produces 4 output bytes. 3. Encoded size = 4 × 1 = 4 bytes. 4. Overhead = (4 - 1) / 1 × 100 = 300%. Padding is included."
}

Related workflows

No source-defined multi-instrument workflow membership is recorded.

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json · VERIFIED_CLEAN
• evidence-tranche5/tranche5-results.json
• BOUNDARY_HAZARD_CATALOG.json