Hex vs Base64 JWT Secrets
Hex encoding
Pros
- Easy to spot-check length (2 hex chars per byte)
- No special characters that complicate shell quoting
- Common in tutorials and .env examples
- Simple to compare visually in diffs
Cons
- Larger strings than Base64 for the same bytes
- Teams sometimes truncate when copying
- Still mistreated as passwords if generated poorly
Base64 / Base64URL encoding
Pros
- More compact than hex for the same entropy
- Familiar from JOSE and Web Crypto exports
- Works well in secrets managers and configs
- Base64URL avoids padding issues in some URLs
Cons
- Padding and URL-safe variants cause mismatches
- Harder to eyeball byte length quickly
- Must decode consistently on every service
Verdict
Encoding does not create entropy — your CSPRNG does. Pick hex or Base64 based on operational comfort, then standardize decoding so every issuer and verifier uses identical raw key bytes. Hex is friendlier in .env files and length checks; Base64 is more compact for the same entropy. The dangerous failures are truncating strings, mixing hex with Base64, treating human passphrases as keys, or decoding twice. Generate at least 256 bits of randomness for HS256, store the encoded form in a secrets manager, document the exact encoding in your platform README, and reject undersized secrets at process boot in production.
Related Tools
Deeper Reading
Frequently Asked Questions
Does Base64 make a secret stronger?
No. Strength comes from random bits. Encoding only changes how those bits are written as text for configuration files and secret stores.
Why do signatures fail after copying a secret?
Often a truncated string, added quotes/whitespace, or hex interpreted as raw ASCII. Compare byte lengths after decoding on every service that signs or verifies.
Should I use Base64URL for env secrets?
You can, but stay consistent. Many teams prefer standard Base64 or hex in env vars to avoid URL-safe alphabet and padding confusion across libraries.
How long should a hex HS256 secret look?
For 256 bits of key material you need 32 bytes, which is 64 hex characters after encoding. Count decoded bytes, not how long the string feels in a password manager UI.