JWT Debugger

Decode, inspect, and verify JSON Web Tokens

Encoded Token

Decoded

Header

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

Payload

{
"sub": "1234567890",
"name": "Ada Lovelace",
"role": "admin",
"iat": 1786698499,
"exp": 1786705699
}

Signature · HS256

ikcZpHFjgZTlYAAAIsP41LJ459WWmSVwIgAlw-_1ykg

A JWT debugger for the moment you need to know what's actually inside a token, not just that it's a token. Paste one in and see the header and payload as readable, colorized JSON, expiration and issued-at claims called out as dates instead of raw timestamps, and — if you have the secret or public key — a live signature check.

Is my token, secret, or private key uploaded anywhere?
No. Decoding and signature verification both run locally via the browser's Web Crypto API — nothing you paste, including a signing secret or private key, is ever sent anywhere. That matters here more than in most tools, since you might be pasting real credentials.
What does "alg: none" mean, and why is it flagged?
It means the token claims to be unsigned. Accepting alg: none tokens is a well-known JWT vulnerability — a client could forge any payload with no signature at all — so the tool calls it out explicitly instead of quietly showing an empty signature.
Which signing algorithms can be verified?
HS256/384/512 with a shared secret, and RS256/384/512 or ES256/384/512 with a PEM-encoded public key (-----BEGIN PUBLIC KEY-----). Other algorithms, like the PS* family, are decoded but not verified yet.
Why do exp, iat, and nbf show as dates instead of numbers?
Per RFC 7519, those claims are Unix timestamps in seconds. The tool converts them to your local time and flags an expired exp or a not-yet-active nbf, so you don't have to do the math by hand.