Source: https://guthlabs.ai/docs/instruments/base-encoding-size-calculator-text-data-bloat/mechanism/

instrument mechanism / verified-clean

# Base Encoding Size Calculator (Text/Data Bloat) mechanism

The inspectable method record for Base Encoding Size Calculator (Text/Data Bloat), kept separate from implementation and qualification.

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## Model scope

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.

- 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.

## Units and conventions

- 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.

## Inspectable vector

One of 4 source-bound review vectors:

````
{
  "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."
}
````

## Failure boundary

**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.

## Other records

[01**Overview**](<https://guthlabs.ai/docs/instruments/base-encoding-size-calculator-text-data-bloat/>)[03**Implementation**](<https://guthlabs.ai/docs/instruments/base-encoding-size-calculator-text-data-bloat/implementation/>)[04**Qualification**](<https://guthlabs.ai/docs/instruments/base-encoding-size-calculator-text-data-bloat/qualification/>)

## Sources and evidence

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

- `VERIFIED_LEDGER.json`

- `evidence-tranche5/tranche5-results.json`

- `BOUNDARY_HAZARD_CATALOG.json`