JWT Decoder

Just Because It Decodes, Doesn't Mean It's Real

This is the most common misunderstanding when first encountering JWTs. This tool can neatly display the header and payload because those parts are simply base64url-encoded JSON. No key or verification is needed. This means that even a completely fabricated token will appear perfectly valid on the screen when you paste it in.

The third part, the signature, is what determines authenticity. The signature is a value calculated from the header and payload using a secret key (for HS256) or a private key (for RS256). Verifying it requires that key. Since the key must remain on the server, a browser-based tool cannot and should not perform signature verification.

Never Paste Production Tokens into Third-Party Sites

A JWT is a credential, often used to prove a user's identity after login. It carries the same effective weight as a password. Pasting a production token into an online decoder that sends data to a server is no different from lending your account to that service's operator. Until it expires, they can use that token to make API calls as you.

This tool does not send anything to our server, and for the same reason, it does not save the tokens you enter into your browser's storage (this tool is an exception, as other tools on this site may autosave for convenience). Still, it's best to build good security habits.

• As a rule, always check tokens from development or test accounts instead of production tokens.
• Pasting tokens into company messengers or issue trackers carries the same risk. If you need to share, capture a screenshot of just the payload.
• If a token is accidentally exposed, don't wait for it to expire. The proper response is to invalidate the session on the server or rotate the signing key.

Common Pitfalls with Time Claims (exp, iat)

The 'exp', 'iat', and 'nbf' claims are Unix timestamps in seconds, not milliseconds. A common mistake in JavaScript is to write `exp: Date.now()`, which results in a value 1000 times too large. This creates a token that expires sometime in the 50,000s, and the server effectively issues a token that never expires. If you see an absurd year in the "Human Readable Time" table, suspect this mistake.

The opposite error is to forget to divide by 1000, setting a past time as the expiration and causing the token to expire upon issuance. The "Remaining/Elapsed Time" column updates every second, so if a freshly issued token already shows as "... ago", check the token creation code first.

• A token without an 'exp' claim is marked with a badge reading "No exp — token never expires". For an access token, this design should be reconsidered.
• If 'nbf' (Not Before) is in the future, the token cannot be used yet. Even a few seconds of clock skew between the issuing and verifying servers can cause a "Not yet valid" error. Verifying servers usually allow a tolerance of a few tens of seconds (clock skew) to account for this.
• The table shows both your local time and UTC time. When comparing a timestamp with server logs, first check which timezone the logs are using. A surprising number of time-related bugs boil down to timezone mismatches.

Why You Can't Trust the Header (or `alg=none`)

An 'alg' value of 'none' in the header means the token is unsigned, and this tool will display a yellow warning. The problem stems from some older libraries that were implemented to "verify using the algorithm specified in the header." An attacker could change the 'alg' to 'none' and remove the signature. The library would approve the token because there was nothing to verify. Modifying the payload to set `role: 'admin'` is the trivial next step.

A related problem is the 'alg' confusion attack. If a server expects RS256 (asymmetric, verified with a public key) and an attacker sends a token with the 'alg' changed to HS256 (symmetric), a naive implementation might mistake the public key for an HMAC secret key. Since the public key is, by definition, public, anyone can then create a valid signature.

What Not to Put in the Payload

The 'Claim Descriptions' table gives you an at-a-glance view of what this token contains. Looking at that list, you should ask yourself one question: is it okay for all of this data to be public? The payload is merely encoded, not encrypted. Anyone who has the token, including browser extensions that can read browser storage, can read its entire contents.

• Personal Identifiable Information (PII) like Social Security Numbers, phone numbers, or home addresses. Don't include them. If the server needs this data, it can look it up using the 'sub' (subject/user ID) claim.
• Values that expose your internal system architecture, such as internal database sequence IDs or admin-only paths.
• Long lists of permissions that bloat the token. A JWT is sent in a header with every single request. Dozens of permissions add that much overhead to every call, and some servers and proxies will reject requests that exceed a header size limit (often 8KB).
• Frequently changing values. A token is a snapshot of data at the moment it was issued. If a user's subscription is downgraded, they can still access premium features with their old token until it expires. This is a primary reason why access tokens should have short lifetimes.