JWT Decoder
Inspect a token’s header and payload, with optional signature verification.
Treat real tokens as credentials
How JWT Decoder works
Decoding a JWT means splitting it on the two dots and Base64URL-decoding the first two parts. That requires no key at all — which is exactly why a JWT’s payload should never be treated as secret. The third part, the signature, is raw bytes and only becomes meaningful when checked against a key.
Verification recomputes the signature over the encoded header and payload and compares it to the one in the token. For HS256 that means running HMAC-SHA-256 with the shared secret; for RS256 and ES256 it means an asymmetric signature check against a public key. A pass proves two things: the token was produced by a holder of the key, and not one byte of the header or payload has changed since.
A structurally valid, correctly signed token can still be unusable. The time claims must be checked separately: exp must be in the future, nbf must be in the past, and most libraries allow a small leeway for clock skew. Beyond that, aud must match your service and iss must be an issuer you trust.
The most consequential JWT vulnerabilities come from trusting the header. A verifier that reads alg from the token and then honours it will accept "alg":"none" tokens, or accept an HS256 token signed with an RSA public key it published. Always pin the expected algorithm in your verification code.
How to use this decoder
Paste the token
Drop in the full three-part token. The header and payload decode instantly, with no key required.
Read the claims
Inspect sub, iss, aud, and any custom claims, and check the decoded exp and iat against the current time.
Verify the signature (optional)
Supply the shared secret or public key to confirm the token is authentic and untampered.
Diagnose the failure
A decode that succeeds but a verification that fails points at the key; a valid signature with a past exp points at expiry.
Worked examples
An expired token
- Given
- A token whose payload contains "exp": 1786500000
- Result
- Decodes cleanly, but expired on 12 August 2026
This is the single most common "my token stopped working" cause — the signature is still perfectly valid.
Wrong audience
- Given
- "aud": "billing-api" presented to the reporting service
- Result
- Signature verifies, authorisation is refused
aud exists so a token minted for one service cannot be replayed against another. A verifier that skips the check loses that protection.
Milliseconds mistaken for seconds
- Given
- "exp": 1786503600000
- Result
- An expiry in the year 58600
A token that never expires is a security bug, not a convenience. NumericDate is defined in seconds.
When to use it
- Working out why an API returned 401 by reading the token’s actual claims instead of guessing.
- Confirming a token was signed with the key you expect before shipping a configuration change.
- Checking exp, nbf, and iat when a login works locally but fails in staging.
- Auditing what personal data your service is placing in tokens that clients can read.
- Teaching or reviewing JWT structure without pasting a live token into a third-party website.
Things to watch out for
- Decoding proves nothing about authenticity. A token can be entirely fabricated and still decode to plausible-looking claims.
- Never paste production tokens into online decoders you do not control — a bearer token is a live credential until it expires. This tool runs entirely in your browser precisely so that pasting one is safe here.
- A failed signature check with a correct-looking token usually means a key mismatch between environments, not a malformed token.
- Reject "alg":"none" unconditionally, and pin the algorithm you expect rather than reading it from the token.
Frequently asked questions
Is my token sent to a server?
No. Splitting, Base64URL decoding, and signature verification all run in your browser via the Web Crypto API. Nothing you paste is transmitted or stored, which is what makes it safe to inspect a live token here.
Do I need a secret to decode a token?
No, and that is the essential point about JWTs: the header and payload are encoded, not encrypted, so anyone holding the token can read every claim. A key is needed only to verify the signature.
What does a failed signature verification mean?
Either the token was altered after signing, or you are verifying with the wrong key. In practice it is nearly always the second — a staging secret checked against a production token, or a rotated key.
Why is my valid token rejected by the API?
Check exp and nbf against the current time first, then aud and iss. A signature can verify perfectly while the token is expired, not yet valid, or minted for a different service.
Is it safe to paste a production token here?
Here, yes — nothing leaves your browser. As a general habit, no: most online decoders transmit what you paste, and a bearer token grants whatever access it encodes until it expires.
What is the "alg: none" attack?
An attacker rewrites the header to claim no algorithm and strips the signature. A verifier that reads the algorithm from the token instead of pinning it server-side will then accept a completely forged payload.
Related Developers tools
All developer tools- Base64 Encode / Decode Encode and decode Base64 for text and files, with URL-safe support.
- Encrypt / Decrypt Text Encrypt and decrypt text with a passphrase (AES-GCM/CBC) or an RSA public key — output as Base64.
- Hash Generator Compute MD5, SHA-1, SHA-256, and SHA-512 digests, or Argon2 password hashes with a pepper.
- JSON Formatter Pretty-print, minify, and validate JSON with precise error positions and a tree view.
- UUID Generator Generate one or thousands of v4 UUIDs and copy them all at once.
- URL Encoder / Decoder Percent-encode or decode URLs and query-string components.