Base64 and URL-safe encoding pitfalls

Base64 looks simple until JWTs, data URLs, and form bugs collide. PracticalKit’s encoding tool focuses on common developer footguns: Standard vs URL-safe alphabets: JWT segments use URL-safe base64 without padding; PEM uses standard alphabet with line wraps. Decoding JWT payload with the wrong alphabet corrupts JSON silently. UTF-8 vs bytes: encoding a Unicode string must UTF-8 encode first, then base64. JavaScript’s btoa breaks on astral characters; our tool documents the correct path. Padding: some APIs reject missing padding; others accept stripped padding. When building HMAC test vectors, match RFC 4648 exactly. Data URLs: the comma separates metadata from payload; mime type affects browser handling. Large data URLs block HTML and confuse CSP. Hex and base64 interop shows up in hash workflows— use /hash/ for digests on the underlying bytes, not on base64 strings unless specified. Teaching goal: one well-explained encoding page beats five duplicate “Base64 encoder” SEO entries. Link from API debugging posts and JWT decode docs for a coherent flagship cluster. Debugging order: alphabet (standard vs URL-safe), padding policy, text-vs-bytes (UTF-8 first?), optional outer URL-encoding, then hashes or signatures. Skipping steps and “trying another online tool” encodes wrong premises. Base64 is not confidentiality—putting a key in a URL after encoding only changes readability. Use /jwt/, /encoding/, and /hash/ as one cluster: structure, alphabet/padding, then byte digests. Watch line wraps in PEM and charset mismatches (Latin-1 bytes decoded as UTF-8) that diverge between local and server results—document byte provenance in API specs and include non-ASCII fixtures. Encoding pages teach interoperability; they are not a substitute for secret storage.