JSON Web Tokens (JWTs) are transmitted as Base64url-encoded strings — and this is one of the three practical places where Base64url encoding (not standard Base64) is specifically required because the +, /, and = characters in standard Base64 would break the token in URL and HTTP header contexts
The previous articles on this site covered Base64 basics, data URLs, email MIME encoding, Base64 vs Base64url, and the 33% size overhead math. This article addresses Base64 in modern web security contexts — specifically the three contexts where Base64 or Base64url appears in security-relevant ways, and the specific encoding choices that each requires.
The three security contexts for Base64 encoding
Context 1: Storing secrets and keys
API keys, signing secrets, and cryptographic material are frequently stored and transmitted as Base64-encoded strings. The encoding choice matters:
Standard Base64 works for storage (in environment variables, configuration files, databases) where the encoded string will never be used directly in a URL or HTTP header. The +, /, and = characters cause no problems in these contexts.
Base64url is required when the encoded value will appear in a URL parameter, Authorization header, or JWT. The + → - and / → _ substitution, plus omitted = padding, ensures URL-safety without percent-encoding.
The specific mistake: generating a 32-byte secret as standard Base64 (aB+cD/eF==) and embedding it directly in a URL query string. The + gets decoded as a space, corrupting the secret.
Context 2: JWT structure — three Base64url sections
A JSON Web Token has three sections separated by dots: header.payload.signature
Each section is independently Base64url-encoded:
Header: a JSON object specifying the algorithm and token type:
{"alg": "HS256", "typ": "JWT"}
Base64url encoded: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload: a JSON object containing claims:
{"sub": "1234567890", "name": "John Doe", "iat": 1516239022}
Base64url encoded: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
Signature: HMAC-SHA256 of header.payload using the secret key, then Base64url encoded.
Why Base64url specifically (not standard Base64): JWTs are frequently transmitted in:
- URL query parameters (
?token=eyJ...) - HTTP Authorization headers (
Authorization: Bearer eyJ...) - Cookies
Standard Base64's + and / would require percent-encoding in URLs, and padding = characters cause issues in HTTP headers. Base64url is the correct choice for all three transport contexts.
Decoding a JWT: any Base64url decoder (including the JWT Decoder tool) can decode the header and payload sections. The payload is not encrypted — it's only encoded. Anyone who holds a JWT can read its claims. JWT's security relies on the signature verification, not on the encoding providing confidentiality.
Context 3: HTTP Basic Authentication
HTTP Basic Auth transmits credentials as standard Base64 (not Base64url) in the Authorization header:
Authorization: Basic dXNlcjpwYXNzd29yZA==
Where dXNlcjpwYXNzd29yZA== is the Base64 encoding of user:password (username and password joined with a colon).
Why standard Base64 (not Base64url) here: HTTP Basic Auth is defined in RFC 7617, which specifies standard Base64. The Authorization header value is an opaque string that HTTP doesn't interpret as a URL component — so +, /, and = are valid characters in this context.
The critical security warning: HTTP Basic Auth transmits credentials in Base64 encoding over the wire — this is NOT encryption. If intercepted (on an unencrypted HTTP connection), the credentials are trivially decoded. Basic Auth must only be used over HTTPS.
Detecting encoding type from the encoded string
Distinguishing standard Base64 from Base64url:
- Contains
+or/: standard Base64 - Contains
-or_: Base64url - Ends with
=or==: standard Base64 (padded) - No trailing
=: Base64url (unpadded) or standard Base64 without padding
Length check: valid Base64 strings have lengths that are multiples of 4 when padded. Base64url typically omits padding, so length modulo 4 may be 0, 2, or 3 (not 1, which would be invalid).
JWT detection: three Base64url sections separated by two dots, where the first section decodes to JSON containing "alg" and "typ" fields.
Base64 in Content Security Policy (CSP): nonces and hashes
Content Security Policy uses Base64-encoded values in two security-relevant ways:
Nonces: a random per-page value generated server-side, Base64-encoded, included in the CSP header and in each script tag:
Content-Security-Policy: script-src 'nonce-2726c7f26c'
<script nonce="2726c7f26c">...</script>
Only inline scripts with the matching nonce can execute — preventing XSS attacks from injected scripts without the nonce.
Hashes: Base64-encoded SHA-256/SHA-384/SHA-512 hashes of allowed inline script content:
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbNI2F5...'
Only inline scripts whose content matches the hash can execute.
The Base64 in nonces and hashes is standard Base64 (per the CSP specification, which requires standard Base64 encoding for hash values and accepts standard or URL-safe for nonces). The single-quote wrapping in the CSP header ('nonce-...', 'sha256-...') distinguishes these from URL values where Base64url would be required.
How to use the Base64 Encoder/Decoder on sadiqbd.com
- For JWT inspection: the tool can decode any of the three JWT sections — paste just one section (the header or payload, without the dots) to see the decoded JSON claims without needing the full token
- For credential storage: when storing API keys or secrets that will be used in URLs, generate using Base64url encoding — the tool shows both standard and Base64url output to enable the correct choice
- For debugging Basic Auth headers: decode the value after "Basic " in an Authorization header to verify the credentials being sent are correct (useful in development/debugging contexts)
Frequently Asked Questions
If JWT payloads are just Base64-encoded (not encrypted), can I put sensitive data in them? No — not unless the JWT is itself encrypted (JWE, not JWS). Standard JWTs (JSON Web Signatures, JWS) sign the payload to prevent tampering but don't encrypt it. The payload can be decoded by anyone who holds the token. Sensitive data — passwords, raw PII, account numbers, health data — should not be included in standard JWT claims. The safe approach: store sensitive data server-side keyed by a non-sensitive identifier, and put only non-sensitive identifiers (user ID, roles, expiry time) in the JWT claims. If you genuinely need to transmit sensitive data in a token, use JWE (JSON Web Encryption) which does provide confidentiality.
Is the Base64 Encoder/Decoder free? Yes — completely free, no sign-up required.
Try the Base64 Encoder/Decoder free at sadiqbd.com — encode and decode Base64 and Base64url strings instantly.
