2026-06-23 · 5 min read · Rahul Chitturi
- base64
- jwt
- oauth
Base64 and Base64url are close enough to look interchangeable in logs, but they are not the same encoding. That tiny difference shows up in JWT segments, OAuth state values, signed URLs, and API tokens that travel through query strings.
When a value decodes locally but fails in production, check the variant before rotating secrets or changing signature code.
Know the character set
Standard Base64 uses plus and slash. Base64url replaces them with dash and underscore so the encoded value can survive in URLs without extra escaping. Padding also differs: many Base64url values omit trailing equals signs even though some decoders expect them.
- Standard Base64: A-Z, a-z, 0-9, +, /, and optional = padding
- Base64url: A-Z, a-z, 0-9, -, _, and often no padding
- JWT header and payload segments use Base64url
- Percent-encoding is separate from Base64url encoding
Do not double-encode state values
OAuth state and redirect parameters often combine JSON, Base64url, and URL encoding. Encode each layer once and decode in the reverse order. If the final authorization URL contains percent signs inside another encoded value, compare each intermediate string before it reaches the provider.
Unicode still starts as bytes
Text must become UTF-8 bytes before either Base64 variant can represent it. Emoji, accented characters, and copied symbols reveal bugs in code that treats JavaScript strings as raw bytes. If a decoded value is garbled, confirm the original charset before blaming the token format.
A Flashman workflow
Decode a copied value with the Base64 tool, inspect JWT segments with the JWT decoder, and use the URL encoder/decoder to verify query parameters around OAuth state. For signed values, never edit the decoded content and reuse the old signature; regenerate the token with the correct signing process.
Keep production secrets out of examples. For debugging, use synthetic values that preserve the same encoding shape without exposing customer data.