Base64 / URL Encoding Converter mechanism

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

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