JWT Decoder

Paste a JSON Web Token to see its decoded header and payload, plus human-readable expiry dates. Decoding happens in your browser — the token is never sent anywhere.

jwt-decode · runs locally
Decoded only — signatures are not verified.

What this JWT decoder shows you

A JSON Web Token looks opaque, but only the signature is cryptographic — the header and payload are plain JSON that has been base64url-encoded. This tool splits the token on its two dots, decodes the first two segments, pretty-prints the JSON, and converts any exp, iat or nbf claims into human-readable UTC dates with a clear expired/valid verdict. The signature segment is displayed as-is: decoding it would just yield raw bytes, and this tool deliberately does not verify it — that requires the issuer’s key and belongs on your server.

Everything happens locally in your browser. Even so, treat live production tokens like passwords: they are bearer credentials, and the safest tokens to inspect are expired ones.

Reading a decoded token

  1. Header — check alg; HS256 means a shared secret, RS256/ES256 a public/private key pair.
  2. Payload — sub identifies the subject; registered claims sit alongside whatever custom claims the issuer added.
  3. Timestamps — exp, iat and nbf are Unix seconds; convert any other epoch values with the Unix Timestamp Converter.

Debugging common JWT problems

Most “invalid token” errors are visible after a decode: an exp in the past (clock skew between servers is a classic), an aud or iss that does not match what the verifier expects, or a token truncated by a header size limit so the third segment is missing. Since the payload is just Base64-encoded JSON, remember that nothing in it is confidential — never put secrets in JWT claims.

Frequently asked questions

Is it safe to paste a JWT into this tool?

The tool runs entirely in your browser — the token is never transmitted, logged or stored, and you can verify that by loading the page and going offline. That said, a live production token is a bearer credential: anyone holding it can use it. Prefer decoding expired tokens or ones from development environments when you can.

What are the three parts of a JWT?

A JWT is three base64url-encoded segments joined by dots. The header states the signing algorithm and token type; the payload carries the claims — user ID, expiry, scopes and any custom data; the signature is computed over the first two parts with the issuer's key, so any tampering invalidates it.

What is the difference between decoding and verifying a JWT?

Decoding just reverses the base64url encoding — anyone can do it, no key required, which is what this tool does. Verifying means recomputing the signature with the issuer's secret or public key to prove the token is authentic and untampered. Servers must always verify; never trust claims from a merely decoded token.

Why is the exp claim a number instead of a date?

JWT timestamps (exp, iat, nbf) are Unix time: seconds elapsed since January 1, 1970 UTC. A bare number is compact, timezone-free and trivial to compare — a validity check is just one integer comparison against the current time. This tool converts them to readable UTC dates for you.

Base64 Encode / Decode

Encode text to Base64 or decode Base64 back to text. Full UTF-8 support.

Open tool →

JSON Formatter

Beautify and pretty-print JSON with 2-space, 4-space, or tab indentation.

Open tool →

Unix Timestamp Converter

Convert Unix epoch timestamps to human-readable dates and back.

Open tool →