Source: https://guthlabs.ai/docs/instruments/base64-url-encoding-converter/mechanism/

instrument mechanism / verified-clean

# Base64 / URL Encoding Converter mechanism

The inspectable method record for Base64 / URL Encoding Converter, kept separate from implementation and qualification.

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

## Model scope

The core conversion concept is valid, but the empty honest_label and unspecified text encoding, Base64 variant/padding policy, URI-component policy, and size-counting convention prevent an unambiguous PASS. The catalog label should state the supported standards and policies, for example: “UTF-8 text and raw bytes; standard RFC 4648 Base64 with padding; RFC 3986 component percent-encoding; spaces encoded as %20, not '+'.”

- The Base64 sizing shorthand must be expressed exactly as 4 × ceil(byte_count / 3), with 0, 1, or 2 '=' padding characters determined by the remainder; plain ÷3×4 is not exact for non-multiples of 3.

- “Percent-encoding per RFC 3986 reserved set” is ambiguous: encoding behavior depends on the URI component and application. RFC 3986 defines reserved and unreserved characters but does not prescribe one universal encode-everything policy for all URL contexts.

- The specification does not define the text-to-byte encoding; UTF-8 is required for deterministic handling of non-ASCII text.

- The specification does not define whether Base64 means standard Base64 or the Base64url alphabet, nor whether padding is mandatory or optional.

- “Byte-size before/after” is ambiguous for text input and Base64 output; the implementation should explicitly report UTF-8 input bytes and ASCII encoded-output bytes, rather than character counts alone.

## Units and conventions

- Text is encoded as UTF-8 before Base64 or percent-encoding.

- Base64 uses the standard RFC 4648 alphabet and includes '=' padding.

- Encoded Base64 and percent-encoded strings are ASCII, so their character count equals their encoded byte count.

- Percent-encoding operates on UTF-8 bytes, uses uppercase hexadecimal digits, leaves RFC 3986 unreserved characters A-Z, a-z, 0-9, '-', '.', '_', and '~' unchanged, and encodes the selected reserved or otherwise unsafe bytes.

- The test vectors use component-style percent-encoding in which '?' and '/' are encoded as %3F and %2F, and spaces are encoded as %20 rather than '+'.

- Decoded text is interpreted as UTF-8 when the output is presented as text.

## Inspectable vector

One of 4 source-bound review vectors:

````
{
  "inputs": {
    "direction": "encode",
    "mode": "base64",
    "text": "Hello",
    "text_encoding": "UTF-8"
  },
  "expected_outputs": {
    "converted_string": "SGVsbG8=",
    "byte_size_before": 5,
    "byte_size_after": 8
  },
  "working": "UTF-8 bytes for “Hello”: H=1, e=1, l=1, l=1, o=1, so 5 bytes. Base64 groups: ceil(5/3)=2 groups. Output size = 2×4 = 8 characters/ASCII bytes. The first 3 bytes encode to “SGVs”; the remaining 2 bytes encode to “bG8=” with one '=' padding character. Result: “SGVsbG8=”."
}
````

## Failure boundary

**BREAK_CLAIMED** · SELF_FLAGGED

Malformed Base64 input of length 1 has no defined decode result and must be rejected. URL encoding also has a genuine convention hazard: RFC 3986 produces %20 for spaces, while form-style encoding produces '+'.

## Other records

[01**Overview**](<https://guthlabs.ai/docs/instruments/base64-url-encoding-converter/>)[03**Implementation**](<https://guthlabs.ai/docs/instruments/base64-url-encoding-converter/implementation/>)[04**Qualification**](<https://guthlabs.ai/docs/instruments/base64-url-encoding-converter/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-tranche4/tranche4-results.json`

- `BOUNDARY_HAZARD_CATALOG.json`