JWT Decoder & Security Analyzer

JWT

JWT Decoder & Security Analyzer

Free · In-Browser · Token Never Uploaded

Paste your JSON Web Token below. Decoding and security analysis happen entirely inside your browser. Nothing is sent to CodeCrackers or any server. Explore our other free developer tools anytime.

Header

{}

Payload

{}

This tool decodes and flags common security issues. It does not verify signatures with your production secret and does not crack tokens. Never paste a live signing key into any website form.

This free online JWT decoder lets you instantly decode any JSON Web Token and inspect its header, payload, and security issues. Whether you are debugging an API login, reviewing a mobile app session, or doing a security pentest, paste your token above and get a full breakdown in seconds. For technical specifications, refer to the official IETF RFC 7519 JWT Standard.

How to Use the JWT Decoder

Copy the token from DevTools, Postman, Burp Suite, or an Authorization: Bearer header.
Paste it into the box above. Decoding starts automatically as soon as the string looks like a JWT.
Read the Header (algorithm, type, kid) and the Payload (claims like sub, exp, iss).
Review the Findings panel. Red items must be fixed before production. Yellow items need server-side validation even if the app currently works.

What Is a JWT Token?

A JSON Web Token (JWT) is the most widely used method for passing authentication and authorization data between a client and a server. Every compact JWT is three Base64URL-encoded pieces separated by dots:

header.payload.signature

The header and payload are plain JSON. Base64URL is encoding, not encryption. Anyone who holds a token can read the first two parts. The signature is the only proof that a trusted party created the token, and only if the server verifies it correctly against the right key.

This is exactly where most real-world applications fail. Libraries that accept alg: none, confuse a public RSA key with an HMAC secret, or skip iss, aud, and exp checks are why JWT security bugs remain common in pentests today.

JWT Header Fields Explained

alg: The signing algorithm. Common values: HS256, RS256, ES256. The dangerous value is none.
typ: Token type, almost always JWT.
kid: Key ID. Used for key rotation. Dangerous if the application fetches a signing key from a URL built from this value without allow-listing.
jku / x5u: Remote key URLs. Treat these as untrusted. If the server fetches and trusts them blindly, that is a pentest finding.

JWT Payload Claims You Must Validate

Claim	Meaning	What to Validate on the Server
iss	Issuer: who created the token	Exact match, not "starts with"
aud	Audience: who the token is for	Must match your API's audience string
sub	Subject: which user or client	A stable ID, not just any email
exp	Expiry time in Unix seconds	Reject if current time is at or after exp
nbf	Not valid before this time	Reject if current time is before nbf
iat	Issued-at timestamp	Helps detect tokens with absurd lifetimes
jti	JWT ID (unique token identifier)	Required if you need token revocation or replay protection

Note: JWT timestamps are Unix seconds, not milliseconds. If exp shows the year 1970 or the year 56,000, the issuer mixed up the units. That is a bug in the token-generation code.

Security Findings This Analyzer Checks

1. alg: none or Missing Algorithm

Critical Risk

Some older JWT libraries accepted none as a valid algorithm, meaning no signature is required. An attacker edits the payload, sets alg to none, removes the signature, and submits. If the server accepts it, any user can impersonate any other user. Always disable none in your JWT library configuration. Never try to catch this in application code alone.

2. HS256 on a Public or Multi-Service API

Review Required

HMAC algorithms like HS256 use a single shared secret. That works for a single backend you fully control. It becomes dangerous when multiple services, mobile apps, or SPAs all validate the same token because every one of them holds the signing secret. A leaked secret means forged tokens for everyone. Use RS256 or ES256 instead. Only the auth server holds the private key, and everyone else verifies with the public key.

3. Expired Tokens Your API Still Accepts

Broken Session Handling

If this decoder marks a token as expired but your API still returns HTTP 200, expiry validation is not running. Common causes: a gateway validates JWT while a legacy internal endpoint does not, clock skew set too generously, or a refresh token being sent where an access token is expected. Fix the server-side check and do not extend token lifetime as a workaround.

4. Missing iss or aud Claims

Skeleton Key Risk

A token issued for your staging API should never be accepted by your production API. If you only verify the signature and skip iss and aud, any valid token from any environment or any other service sharing the same key becomes a skeleton key. Validate both claims explicitly, with exact string matching, on every request.

5. Sensitive Data in the Payload

Data Exposure

The JWT payload is Base64URL-encoded, not encrypted. Anyone who intercepts or steals the token can instantly read everything in it. User email is common and usually acceptable. Passwords, API keys, credit card numbers, and raw session tokens must never appear in a JWT payload. If you need the data to be unreadable, use JWE (JSON Web Encryption) or keep the sensitive fields out of the token entirely.

6. kid Header Present

Test for Key Injection

The kid claim tells the server which key was used to sign the token. If the server uses kid to fetch a key from a URL or a file path without strict allow-listing, an attacker can inject a key they control. Test with values like ../../tmp/evil or a URL pointing to your own JWKS endpoint. The safe pattern is that kid is a fixed identifier that maps to a key stored locally. Nothing should ever be fetched from the token itself.

Decoding Is Not Authentication

Important: Decoding a JWT does not mean it is valid.

This decoder will happily decode a token signed with the word password as the secret, or one with no signature at all. Your API must verify the signature with a pinned algorithm and the correct key, reject none, check exp, nbf, iss, and aud, and only then trust the sub and scope claims. Skipping signature verification makes all other checks meaningless.

How Pentesters Get the JWT Token

Browser DevTools, Application tab, then Local Storage, Session Storage, or Cookies
DevTools Network tab, look in request headers for Authorization: Bearer ...
Burp Suite or OWASP ZAP HTTP history where every request is captured
Mobile apps using Frida, objection, or an intercepting proxy with TLS unpinning on a device you own and are authorised to test
Server logs where tokens should never appear. If they do, that is itself a security finding

Only paste tokens from systems you have written authorisation to test. JWT payloads often contain personal data.

Developer Best Practices for JWT

Use this decoder to inspect claims while you build and debug. Catch issues before they reach production.
Set access token lifetime to 15 minutes. Use refresh tokens for extended sessions. Never issue 7-day access tokens because refresh was hard to implement.
Keep your signing secret or private key out of Git, CI configs, and any public-facing application code.
Pin the expected algorithm on the server. Do not trust the alg header from the incoming token.
Validate iss, aud, exp, and nbf on every single request, not just on login.

Common JWT Mistakes in Production Apps

Access tokens with a 7-day lifetime because refresh logic was skipped
The same HS256 secret used across Git, CI, staging, and production
aud claim set in the token but never validated by the API
A custom claim like admin: true in a token the client can re-request at will
PII or passwords stored in the payload under the assumption that JWT is encrypted
Accepting tokens from any iss that shares the same parent domain

None of these require a sophisticated exploit. They only require reading the token, which is exactly what this page is for. Check out our free developer & freelancer tools for more calculators and decoders.

What This JWT Decoder Will Not Do

It will not crack HS256 secrets. For authorised engagements, use Hashcat or jwt-cracker locally with a wordlist you have permission to use.
It will not verify signatures against your server. There is no test against production button and that is intentional. Your signing key belongs only on your auth server.
It will not decrypt JWE tokens. JWE has five dot-separated segments and requires the recipient's private key. If you see five segments, you have an encrypted token, not a standard JWT.

Frequently Asked Questions

Is it safe to paste a JWT token here?

Yes. Decoding runs entirely in your browser using JavaScript. Your token is never sent to CodeCrackers or any server. You can verify this by opening DevTools Network tab and watching for outgoing requests when you paste. That said, treat live production tokens as sensitive data. Use staging or test tokens when possible.

Does this JWT decoder verify the signature?

No. Signature verification requires the signing secret or the issuer's public key. Those must stay in your application and never in a browser tool. This decoder only Base64URL-decodes the header and payload and analyzes the claims. Verification must happen on your server.

Why does my JWT token show as expired when the app still works?

There are three common reasons. The app is not checking the exp claim at all. The server allows excessive clock skew. Or you pasted a refresh token instead of an access token. Refresh tokens intentionally live longer. Check which token the app is actually sending in the Authorization header.

What does alg: none mean and why is it dangerous?

alg: none means the token carries no signature. Some JWT libraries historically accepted this as valid, allowing an attacker to forge any token by simply setting the algorithm to none and removing the signature. Always configure your library to reject none explicitly.

Should I use HS256 or RS256 for my API?

Use HS256 only when a single, private backend service both creates and validates tokens. Use RS256 or ES256 when multiple services or clients need to validate tokens. The auth server keeps the private key and everyone else uses the public key. Always pin the expected algorithm on the server regardless of which you choose.

Can I decode a JWE encrypted token here?

No. JWE tokens have five dot-separated parts and the payload is encrypted, not just Base64-encoded. Decrypting requires the recipient's private key. If your token has five segments, it is a JWE and you need to decrypt it with your private key first before the claims are readable.

Why do the dates in my JWT look wrong, like year 1970 or year 56000?

JWT timestamps are Unix seconds. If your token issuer accidentally used milliseconds, dividing the exp by 1000 will give you the intended date. The year 1970 means the value is 0 or very small. The year 56000+ means milliseconds were used instead of seconds. Fix the token generation code on the issuer side.

Do you store tokens or use them for ads or training?

No. The textarea content is never submitted to our server. Ads on the page, if present, receive no data from this tool. The entire decode and analysis process happens inside your browser tab and goes nowhere else.

What is the difference between JWT, JWS, and JWE?

JWT is the general term for JSON Web Tokens. A JWS (JSON Web Signature) is a signed JWT. It is the three-part format most people mean when they say JWT. A JWE (JSON Web Encryption) is an encrypted token with five parts. This tool handles JWS tokens. If you have a JWE, decrypt it first with your private key.

Explore all our Free Developer Tools and read the official IETF JWT Standard.