JWT Decoder
Paste a JWT to decode the header and payload claims. Timestamps auto-convert to human dates with relative time. Color-coded parts, expiry status, copy as JSON.
The three parts of a JWT
Contains the token type (typ: JWT) and the signing algorithm (alg: RS256, HS256, ES256, etc.). The kid field identifies which signing key was used when rotating keys.
The claims — facts about the user or session. Standard claims: sub (subject/user ID), iss (issuer), aud (audience), exp (expiry), iat (issued at). Custom claims like roles, email, and org_id are app-defined.
Cryptographic signature of the encoded header and payload. Verifying it requires the signing key (HMAC secret or RSA/EC public key). Client-side decoding without verification is safe for reading claims — never for authorization.
Standard JWT claims
Registered claims defined by RFC 7519
| Claim | Name | Description |
|---|---|---|
| iss | Issuer | Who issued the token — usually an auth server URL |
| sub | Subject | Who the token is about — typically a user ID |
| aud | Audience | Who the token is intended for — API or service URL |
| exp | Expiration | Unix timestamp after which the token is invalid |
| nbf | Not Before | Unix timestamp before which the token is invalid |
| iat | Issued At | Unix timestamp when the token was issued |
| jti | JWT ID | Unique identifier — prevents replay attacks |
Frequently asked questions
Is it safe to decode a JWT in the browser?
Reading the header and payload is always safe — JWTs are not encrypted by default. The content is base64url-encoded, not secret. What the browser cannot do is verify the signature (that would require the signing key or JWKS endpoint). Never use client-side decoded claims for authorization decisions — always verify server-side.
What is the difference between JWT decoding and JWT verification?
Decoding reads the header and payload by reversing the base64url encoding — no key needed. Verification checks the cryptographic signature to confirm the token was issued by the expected party and hasn't been tampered with. This tool decodes only. For verification, use a JWT library (jsonwebtoken for Node.js, PyJWT for Python, etc.) with your signing key.
Why does my JWT payload show exp as a number?
The exp, iat, and nbf claims are Unix timestamps — the number of seconds since January 1, 1970 UTC. This tool automatically converts them to human-readable dates and shows relative time (e.g., 'expired 3h ago'). To convert manually: new Date(exp * 1000).toISOString().
What algorithms can JWTs use?
HMAC symmetric: HS256, HS384, HS512 — the same secret signs and verifies. RSA asymmetric: RS256, RS384, RS512 — private key signs, public key verifies. ECDSA: ES256, ES384, ES512 — more compact than RSA. EdDSA (Ed25519) — modern and efficient. 'none' — unsigned tokens (never use in production). The alg field in the header tells you which was used.
My token has 5 parts instead of 3 — what is it?
A 5-part token (xxxxx.xxxxx.xxxxx.xxxxx.xxxxx) is a JWE (JSON Web Encryption) rather than a JWT. JWEs encrypt the payload — you cannot decode the claims without the decryption key. JWTs have exactly 3 parts. If you're seeing 5, the token content is encrypted, not just signed.
Related Tools
All conversions run in your browser — nothing is uploaded.
Browse all 26 converters →