JWT Decoder

Decode and inspect JSON Web Token headers, payloads, and expiry claims — no verification, fully local.

JWT Decoder

Decode and inspect JSON Web Tokens locally. No verification — decode only.

Paste JWT Token

How to use JWT Decoder

1
Paste your JWT token into the input box.
2
The header, payload, and claims are decoded instantly.
3
Check the Claims Summary for expiry (exp), issued-at (iat), and not-before (nbf).

Frequently Asked Questions

Is it safe to paste a production JWT token here?

All decoding happens locally in your browser — nothing is sent to any server. That said, avoid pasting tokens with sensitive permissions in shared or public computer environments.

Does this tool verify the JWT signature?

No — decoding and verification are different operations. Decoding reads the base64url-encoded payload. Verification checks the cryptographic signature using the secret key, which must be done server-side.

What is the structure of a JWT?

A JWT has three dot-separated parts: Header (algorithm and token type), Payload (claims — user ID, roles, expiry), and Signature (HMAC or RSA hash of header + payload using a secret). Only the payload contains meaningful data for most use cases.

What claims should I look for in the payload?

Key standard claims: exp (expiry timestamp), iat (issued at), nbf (not valid before), sub (subject — usually user ID), iss (issuer). Expired tokens have exp values in the past.

Why does my JWT show "invalid token"?

Common causes: the token is truncated (copy the full string including dots), the token has expired and the tool is flagging the exp claim, or the string contains extra whitespace characters.

Can I put sensitive user data in a JWT payload?

No — JWT payloads are base64url-encoded, not encrypted. Anyone who intercepts the token can read the payload. Never store passwords, credit card numbers, or private personal data in a JWT payload.

What's Inside That Token?

A JWT bouncing between your frontend and backend is just a string of three base64-encoded segments. It looks like this:

eyJhcGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEwNDIiLCJuYW1lIjoiQXJ5YW4gU2luZ2giLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MDk0MDM2MDB9.SIGNATURE

To debug authentication failures, verify claims, or audit what data your auth server is embedding — you need to read what's inside. This tool decodes all three segments instantly, renders the claims in a clean readable format, and highlights expiry status automatically. Your token never leaves your device.

JWT Structure: Three Parts

[Header].[Payload].[Signature]

Header — a JSON object declaring the token type and signing algorithm:

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

Payload — a JSON object containing claims about the user or session:

{
  "sub": "user_1042",
  "name": "Aryan Singh",
  "role": "admin",
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com",
  "iat": 1709317200,
  "exp": 1709403600
}

Signature — cryptographic proof that the header and payload haven't been tampered with. Computed using a secret key (HMAC) or private key (RSA/ECDSA). Without the secret, the signature can't be verified — and this tool doesn't ask for it.

Both the header and payload are encoded with Base64URL (a URL-safe variant of Base64 that uses - instead of + and _ instead of /). Decoding them reveals the JSON above.

Standard JWT Claims to Know

Claim	Meaning	Format
`sub`	Subject — identifies the user/entity	String (usually an ID)
`iss`	Issuer — who created the token	URL string
`aud`	Audience — intended recipient	String or array
`exp`	Expiration time	Unix timestamp (seconds)
`iat`	Issued At — when token was created	Unix timestamp (seconds)
`nbf`	Not Before — token invalid before this time	Unix timestamp (seconds)
`jti`	JWT ID — unique token identifier	String

This tool automatically converts exp, iat, and nbf from Unix timestamps to human-readable date/time strings, and shows whether the token is expired.

Important: Decoding vs. Verification

Decoding reads the content of the header and payload segments — it only requires base64url decoding.

Verification cryptographically confirms the signature — it requires the server's secret key (for HMAC) or public key (for RSA/ECDSA), and runs a full signature comparison.

This tool decodes but does not verify. A decoded token that shows exp as valid does not mean the token is authentic — the signature hasn't been checked. A maliciously crafted token would also decode successfully here.

For security decisions: never trust JWT content decoded from the client side alone. Signature verification must happen on the server.

When Development Teams Use This

Debugging 401 Unauthorized errors: Paste the token from the request's Authorization: Bearer ... header. Check: Is exp in the past? Is aud pointing to the right service? Is iss what your server expects?

Building auth flows: During development of login or SSO systems, paste tokens from your auth server to verify the correct claims are being embedded — user ID, roles, permissions, tenant ID.

Security auditing: JWTs are only encoded, not encrypted. Any data in the payload is readable by anyone who intercepts the token. Audit your tokens to confirm no unnecessary PII (emails, full names, phone numbers) is embedded without business justification.

Teaching junior developers: The color-coded three-segment display makes JWT structure immediately visual and educational. Showing a decoded token during onboarding is more effective than describing the format abstractly.

OAuth and SSO integration: When integrating third-party OpenID Connect providers (Google, Microsoft, Auth0), decode the ID token to see what user profile claims are returned and how to map them.

Security Best Practices

Keep payloads minimal. Include only the claims your application actively needs: user ID, role, permissions. Embedding unnecessary data increases the token size and exposes more information if intercepted.

Set short expiry times. Access tokens should expire in 15–60 minutes. Long-lived tokens increase the damage window if stolen. Use refresh tokens with rotation for longer sessions.

Scope tokens with the aud claim. A token issued for your API should specify your API in the audience. This prevents tokens issued for one service being replayed against another.

Never paste live production tokens in shared tools. Even local-processing tools should not receive production tokens in contexts where they could be logged by browser extensions, copied to clipboard histories, or observed on screen.