JWT Decoder — Inspect JSON Web Token Claims Free, No Upload

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.

Related Developer Tools

JSON Formatter — Format and validate the JSON payload content
Base64 Encode/Decode — Manually decode individual JWT segments
UUID Generator — Generate unique IDs for the jti claim
Cron Expression Generator — Schedule token refresh jobs

Recommended schema: SoftwareApplication + FAQPage