[P1] Audit: Base64 URL-safe behavior is unclear in decode workflows

[baixiangcpp]

Imported from the byteflow.tools deep audit on 2026-06-22.

Problem: Base64 Encode/Decode exposes operation and input type controls, including URL-safe mode. In decode workflows, the URL-safe behavior is not clear enough. Users working with JWT-like segments, URL tokens, or unpadded Base64URL strings need explicit guidance.

Affected URL:

• https://byteflow.tools/en/base64-encode-decode

Reproduction steps:

1. Open Base64 Encode/Decode.
2. Switch between Encode and Decode.
3. Try normal Base64 and URL-safe Base64 strings.
4. Check how padding, dash/underscore alphabet, and invalid length are explained.
5. Observe disabled or unavailable states for URL-safe options.

Expected behavior: Decode mode should clearly support or explain URL-safe Base64 behavior, including missing padding and alphabet differences.

Actual behavior: the mode behavior is not explicit enough, and users may not know which input type to choose.

Impact: token debugging and integration work can fail silently or require trial and error.

Proposed fix:

• Add a short help note for Base64 vs Base64URL.
• Support unpadded Base64URL decode where safe.
• Show precise error messages for invalid alphabet, invalid length, and missing padding.
• Add examples for normal Base64, URL-safe Base64, and JWT segments.
• Add round-trip checks in tests.

Acceptance criteria:

• Base64URL decode behavior is documented in the UI.
• Common unpadded URL-safe examples decode correctly or produce actionable errors.
• Error messages explain padding and alphabet issues.
• Tests cover normal, URL-safe, invalid, and unicode inputs.

[baixiangcpp]

Closed as completed by the canonical BF audit backlog work. This older non-BF audit issue duplicates work now merged through PRs #209-#219, with the BF issues closed and guard/test coverage in place. The remaining non-duplicate follow-up is #7, which stays open because the upstream Next/PostCSS advisory is not fixed yet.