JWT Decoder
JWT decoder that verifies signatures with a secret or public key in your browser. Shows claims, expiry status, and header warnings.
Updated
A "Bearer " prefix and quotes around the token are removed.
The HMAC key, as text unless Options says otherwise.
Options
A PEM public key or certificate, a JWK, or a JWKS.
Paste a JWT to decode its header and claims. Add the secret or public key to check the signature.
What Is a JWT Decoder?
The JWT decoder splits a JSON Web Token into its header, payload, and signature and shows the registered claims with UTC dates and an expiry status. Paste a secret, a PEM public key or certificate, a JWK, or a JWKS to verify the signature with your browser's Web Crypto API. Warnings point out unsigned tokens, short HMAC secrets, small RSA keys, external key URLs, and timestamps in milliseconds, each with the RFC rule behind it. Encrypted tokens (JWE) are recognized and their header is shown.
How to Use the JWT Decoder
- Paste the token. A leading "Bearer " or "Authorization: Bearer " and surrounding quotes are removed.
- Read the header, the claims, and the expiry status.
- To check the signature, paste the secret for HS algorithms, or the public key, certificate, JWK, or JWKS for the others.
- Read the warnings, then copy the header or payload JSON if you need it.
How It Works
A JWT is always a JWS or a JWE in compact serialization (RFC 7519). A JWS has three segments separated by dots: the header, the payload, and the signature. A JWE has five. Each segment is base64url, which is base64 with the URL-safe alphabet, no trailing = characters, and no line breaks or whitespace (RFC 7515).
Decoding needs no key. The JWS mechanisms protect the integrity of the payload, not its secrecy, so anyone who holds the token can read its claims. RFC 7519 notes that a JWT may contain privacy-sensitive information and names an encrypted JWT as one way to protect it.
The signature covers the ASCII bytes of the header segment, a dot, and the payload segment exactly as received (RFC 7515). The decoder checks it with the Web Crypto API in your browser: HMAC for HS256, HS384, and HS512; RSASSA-PKCS1-v1_5 for RS256, RS384, and RS512; RSASSA-PSS with a salt as long as the hash output for PS256, PS384, and PS512; ECDSA with R and S joined for ES256, ES384, and ES512; and Ed25519 for EdDSA and Ed25519.
The time claims exp, nbf, and iat are NumericDate values: the number of seconds from 1970-01-01T00:00:00Z UTC, ignoring leap seconds (RFC 7519). A token must not be accepted on or after its exp time, or before its nbf time. Verifiers may allow a few minutes of leeway for clock skew; the decoder applies none, so the status shows the exact times.
RFC 8725 sets out what a verifier should check. Libraries must let the caller choose the algorithms they accept, because an attacker can change alg to none and some libraries would then skip the signature check. Human-memorizable passwords must not be used directly as HMAC keys. A kid value should be validated before it reaches an SQL or LDAP lookup, jku and x5u URLs should be matched against allowed locations, and the audience must be checked. The decoder's warnings follow these rules.
HS256 needs a key of at least 256 bits, HS384 at least 384 bits, and HS512 at least 512 bits, the size of the hash output. RS and PS algorithms need RSA keys of 2048 bits or more (RFC 7518). The decoder still checks a signature made with a shorter key and warns about its size.
Signature Algorithms
| alg | Algorithm |
|---|---|
| HS256 | HMAC using SHA-256 |
| HS384 | HMAC using SHA-384 |
| HS512 | HMAC using SHA-512 |
| RS256 | RSASSA-PKCS1-v1_5 using SHA-256 |
| RS384 | RSASSA-PKCS1-v1_5 using SHA-384 |
| RS512 | RSASSA-PKCS1-v1_5 using SHA-512 |
| ES256 | ECDSA using P-256 and SHA-256 |
| ES384 | ECDSA using P-384 and SHA-384 |
| ES512 | ECDSA using P-521 and SHA-512 |
| PS256 | RSASSA-PSS using SHA-256 and MGF1 with SHA-256 |
| PS384 | RSASSA-PSS using SHA-384 and MGF1 with SHA-384 |
| PS512 | RSASSA-PSS using SHA-512 and MGF1 with SHA-512 |
| none | No digital signature or MAC performed |
| EdDSA | EdDSA (deprecated in favor of Ed25519) |
| Ed25519 | EdDSA using the Ed25519 parameter set |
Registered Claims
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Identifies the principal that issued the JWT. |
| sub | Subject | Identifies the principal that is the subject of the JWT. |
| aud | Audience | Identifies the recipients the JWT is intended for: one string, or an array of strings. |
| exp | Expires | The time on or after which the JWT must not be accepted for processing. |
| nbf | Not before | The time before which the JWT must not be accepted for processing. |
| iat | Issued at | The time at which the JWT was issued. |
| jti | Token ID | A unique identifier for the JWT. |
Header Parameters
| Parameter | Name | Meaning |
|---|---|---|
| alg | Algorithm | The cryptographic algorithm used to secure the JWS. |
| typ | Type | The media type of the complete JWS. |
| cty | Content type | The media type of the payload. JWT means the payload is a nested JWT. |
| kid | Key ID | A hint indicating which key was used to secure the JWS. |
| jku | JWK Set URL | A URI for a set of JSON-encoded public keys, one of which signed the JWS. |
| jwk | JSON Web Key | The public key that corresponds to the key used to sign the JWS. |
| x5u | X.509 URL | A URI for the X.509 certificate or chain of the signing key. |
| x5c | X.509 certificate chain | The X.509 certificate or chain of the signing key. |
| crit | Critical | Extensions that must be understood and processed. |
| enc | Encryption | Present in a JWE and absent in a JWS. |
Standards
Scope
What It Checks
- +Decodes the header and payload of a JWS and shows registered claims with UTC dates and an expiry status.
- +Verifies HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512, and EdDSA/Ed25519 signatures with Web Crypto.
- +Accepts a secret (text or base64url), a PEM public key, a PEM certificate, a JWK, or a pasted JWKS.
- +Warns about alg none, short HMAC secrets, small RSA keys, jku, x5u, kid, crit, duplicate names, and millisecond timestamps.
- +Detects encrypted tokens (JWE) and shows their header.
What It Does Not Check
- -It does not decrypt JWE tokens.
- -It does not fetch keys from jku, x5u, or JWKS URLs.
- -It does not check issuer, audience, or token revocation for your application.
- -It does not store the token or key, or put either in the URL.
- -It does not verify ES256K, Ed448, or unencoded-payload (b64 false) tokens.
Defensive Use
RFC 8725, the JWT best current practices, requires an application to check that the keys used for a JWT belong to its issuer, and to reject a JWT whose audience is missing or does not name the recipient. Decoding a token shows its alg, iss, aud, and exp, so a reviewer can compare what a service accepts with what it should accept. The warnings flag the token properties those practices address: unsigned tokens, HMAC secrets shorter than the hash, key URLs in the header, and tokens without an expiry.
Frequently Asked Questions
What is a JWT Decoder?→
The JWT decoder splits a JSON Web Token into its header, payload, and signature and shows the registered claims with UTC dates and an expiry status. Paste a secret, a PEM public key or certificate, a JWK, or a JWKS to verify the signature with your browser's Web Crypto API. Warnings point out unsigned tokens, short HMAC secrets, small RSA keys, external key URLs, and timestamps in milliseconds, each with the RFC rule behind it. Encrypted tokens (JWE) are recognized and their header is shown.
What is the JWT Decoder used for?→
Debugging authentication during development and incident response: reading the claims of an access or ID token, finding out why a signature check fails, confirming which key and algorithm a token uses, and checking when a token expires.
Is my data sent anywhere?→
No. The JWT Decoder runs in your browser. What you enter stays on this page and is not sent to ImmunitySec or anyone else.
How is the JWT Decoder used defensively?→
RFC 8725, the JWT best current practices, requires an application to check that the keys used for a JWT belong to its issuer, and to reject a JWT whose audience is missing or does not name the recipient. Decoding a token shows its alg, iss, aud, and exp, so a reviewer can compare what a service accepts with what it should accept. The warnings flag the token properties those practices address: unsigned tokens, HMAC secrets shorter than the hash, key URLs in the header, and tokens without an expiry.
Can I decode a JWT without the secret key?→
Yes. The header and payload are base64url-encoded JSON, not encrypted. A JWS protects the integrity of its payload, not its secrecy (RFC 7515). The secret or public key is needed only to check the signature. An encrypted JWT (JWE, with five segments) is different, and this decoder shows only its header.
Is it safe to decode a JWT online?→
A JWT may contain privacy-sensitive information (RFC 7519), and a bearer token gives access to any party that holds it (RFC 6750). This decoder runs in your browser, keeps the token and key out of the URL and browser storage, and sends nothing. For production tokens, prefer an expired token or a test token, or revoke the token after debugging.
Why is my JWT signature invalid?→
The signature covers the header and payload segments exactly as they were sent, so any change to either breaks it (RFC 7515). Other causes the decoder names: the wrong key, a secret entered as text when it is base64url-encoded, a key type or curve that does not match alg, and an ECDSA signature in DER form instead of R and S joined (RFC 7518).
What does alg none mean in a JWT?→
An unsecured JWS uses the alg value none and must have an empty signature (RFC 7518). RFC 8725 describes how an attacker can change alg to none and how some libraries would then accept the token without checking any signature, so a verifier should accept only the algorithms it expects.
Are exp and iat in seconds or milliseconds?→
Seconds. A NumericDate is the number of seconds from 1970-01-01T00:00:00Z UTC, ignoring leap seconds (RFC 7519). A value in milliseconds is 1,000 times too large; the decoder warns when a time claim is above 100,000,000,000, which as seconds would fall in the year 5138.
What is the difference between JWS and JWE?→
A JWS has three segments and a JWE has five. If the header has an enc member, the token is a JWE; otherwise it is a JWS (RFC 7516). A JWS is signed and readable, while a JWE is encrypted. The decoder shows a JWE's header and segment sizes but does not decrypt it.
What is an at+jwt token?→
RFC 9068 defines a JWT profile for OAuth 2.0 access tokens. Such tokens declare the type in the typ header parameter, and the value used should be at+jwt. The decoder labels these tokens in the Type row.