JWT Decoder, Signature Verifier & Debugger
Inspect JSON Web Token headers and payload claims, track live token expiration countdowns, and verify HMAC secrets locally.
Encoded Token String
Paste JWT BelowVerify HMAC Secret Key (HS256)
Active Token (Valid)
Decoded Header: Algorithm & Token Type
JSON Object{
"alg": "HS256",
"typ": "JWT"
}
Decoded Payload: Data Claims & Permissions
JSON Claims{
"sub": "auth0|6482910fa",
"name": "Sarah Jenkins",
"email": "sarah.jenkins@company.io",
"role": "admin",
"iat": 1723900000,
"exp": 1755436000
}
Click "Run AI Security Audit" to check for 'alg: none' bypass attacks, key-confusion vulnerabilities (RS256 vs HS256), and sensitive data leakage in payload claims. Your token is 100% private to you—zero server access.
Zero Data Access: All decoding, base64 operations, and cryptographic verifications run 100% locally. Zero Server Access
The 'alg: none' Authentication Bypass: How a Simple JWT Header Exploit Allowed Attackers to Forge Admin Tokens
A technical breakdown of JWT signature validation flaws, asymmetric key confusion attacks, and securing microservice tokens.
The 'None' Algorithm Flaw
The original RFC 7519 specification included an "alg": "none" option for unsigned tokens. Many popular open-source libraries naively trusted the header's algorithm without server-side enforcement. Attackers changed "alg": "HS256" to "none", altered their payload role to "role": "admin", stripped the signature, and bypassed authentication completely across thousands of web applications.
The 3 Critical JWT Security Best Practices
Reject 'none' unconditionally
Hardcode algorithms=['RS256']
Never let the client specify alg.
15-minute access tokens
Pair with rotating refresh tokens
Limits token theft exposure.
Payloads are not encrypted!
Anyone can Base64 decode
Store only user IDs and scopes.
Symmetric (HS256) vs. Asymmetric (RS256 / ES256) JWTs
| Cryptographic Type | Key Management | Microservice Security | Use Case |
|---|---|---|---|
| HS256 (HMAC-SHA256) | Shared Single Secret | Vulnerable if 1 service is compromised | Monolithic backends & single servers |
| RS256 (RSA-SHA256) | Public / Private Keypair | Services only hold Public Key (Cannot forge) | Auth0, Firebase, Enterprise OAuth |
| ES256 (ECDSA P-256) | Elliptic Curve Keypair | Highest security per key length | Apple Sign-In, modern mobile auth |
Encoding is NOT Encryption!
A standard JWT is Base64URL-encoded, not encrypted. Any client, proxy, or man-in-the-middle can read all payload claims in plain text. Never place passwords, credit card numbers, or sensitive PII inside a JWT payload unless using JSON Web Encryption (JWE).
Frequently Asked Questions (JWT Tokens)
What is a JSON Web Token (JWT) and how does it work?
A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. It consists of three parts separated by dots (.): Header, Payload, and Signature.
Is it safe to decode a JWT online in a web browser?
Yes, on Core-AI this tool is 100% client-side. Your JWT tokens, payload claims, and secrets never leave your browser or get transmitted to any remote server.
What is the 'alg: none' JWT vulnerability?
The 'alg: none' vulnerability occurs when a vulnerable backend server accepts JWTs whose header algorithm is set to 'none' without verifying any cryptographic signature, allowing malicious attackers to modify payload claims (such as becoming an admin) arbitrarily.