JSON Web Tokens (JWTs) are the most common format for authentication tokens in modern web APIs — used by Auth0, Firebase, AWS Cognito, Clerk, and most OAuth2 providers. Knowing how to decode and inspect a JWT is a core skill for any developer working with APIs or debugging authentication flows.

What is a JWT?

A JWT is a compact, URL-safe string that carries claims (pieces of information) signed by the issuer. It looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkphbmUifQ.signature

The three parts separated by dots are: Header · Payload · Signature. Each part is Base64URL encoded (not encrypted) — the header and payload can be read by anyone. The signature is what prevents tampering.

The three parts explained

Header

Describes the token type and signing algorithm. Typically:

{
  "alg": "HS256",
  "typ": "JWT"
}

The alg field matters for security — HS256 uses a shared secret (symmetric), while RS256 and ES256 use public/private key pairs (asymmetric). Never accept tokens with "alg": "none" — this disables signature verification entirely.

Payload

Contains the actual claims. Standard claims include:

sub — Subject. Who the token is about (usually a user ID).
iss — Issuer. Who created and signed the token.
aud — Audience. Which service(s) should accept this token.
iat — Issued At. Unix timestamp of when the token was created.
exp — Expiration. Unix timestamp after which the token is invalid.
nbf — Not Before. Token must not be accepted before this time.

Custom claims (roles, permissions, email, etc.) can be added alongside these.

Signature

Created by signing base64url(header) + "." + base64url(payload) with the secret or private key. This ensures the token hasn't been tampered with. Decoding a JWT is easy — verifying it requires the correct key.

How to decode a JWT using inspectly.dev

Go to inspectly.dev/jwt
Paste your token — raw format or as an Authorization: Bearer ... value
The tool instantly shows the decoded header and payload
Check the status bar: Active, Expired, Expiring Soon, or No Expiry
Review the Security Analysis for algorithm warnings and missing claims
For HS256/HS384/HS512 tokens, enter your secret to verify the signature client-side

Security things to check when inspecting a JWT

Algorithm — Is it none? Reject immediately. Is it symmetric (HS256)? The secret must be kept private and rotated regularly.
Expiry — Does it have an exp claim? Tokens without expiry are a security risk if stolen.
Issuer — Always verify iss matches your expected token issuer in code.
Audience — Always verify aud matches your service to prevent token confusion attacks.
Lifetime — Access tokens should expire in minutes to hours. Anything over 24 hours should use refresh tokens instead.

Frequently asked questions

Is it safe to paste a JWT into an online decoder?

With inspectly.dev, yes — all decoding happens in your browser. Your token is never transmitted to any server. The payload is not encrypted, so any decoder can read it. For extra caution with production tokens carrying sensitive PII, use private browsing mode.

What's the difference between decoding and verifying a JWT?

Decoding just reads the Base64URL-encoded data — anyone can do it with no key. Verifying checks that the signature is valid for the given header and payload using the secret or public key. Always verify in your backend code; never trust a JWT's claims without verification.

Why does my JWT fail to decode?

Common causes: the token is truncated (copy the full string including all three parts), it uses non-standard encoding, or there's extra whitespace. Our tool also auto-strips the Bearer prefix if you paste from an Authorization header.

Can I verify an RS256 or ES256 token online?

Our tool currently supports HMAC verification (HS256/HS384/HS512) client-side. For RS256/ES256, you need the public key — verification with asymmetric keys is on our roadmap.

Open JWT Analyzer →