JWT Decoder

Paste a JSON Web Token to inspect its header, payload, claims, and expiry.

Free No signup Token never uploaded Expiry check
JWT Token
Header
Payload
Signature
Advertisement

What is a JWT token?

Three parts

A JWT has three Base64URL-encoded sections separated by dots: Header (algorithm), Payload (claims/data), and Signature (verification).

Not encrypted

JWTs are encoded, not encrypted. Anyone can decode the header and payload. Never put sensitive data (passwords, secrets) in a JWT payload.

Common claims

sub = subject (user ID), exp = expiry timestamp, iat = issued at, iss = issuer, aud = audience.

JWT Tokens — Structure, Claims, and How to Inspect Them

A JSON Web Token is a compact, URL-safe credential that proves a user's identity without requiring a database lookup on every request. Instead of storing session state on the server, the server signs a token and sends it to the client. The client includes the token in every subsequent request. The server verifies the signature — if valid, the token's claims are trusted without any database query.

The three-part structure

Every JWT is three Base64URL-encoded strings separated by dots. The header specifies the signing algorithm ("alg":"HS256"). The payload contains claims — the actual data: user ID (sub), expiry time (exp), issue time (iat), and any custom data your application needs. The signature is a cryptographic hash of the header and payload, signed with a secret key only the server knows.

JWTs are encoded, not encrypted

This is critical: anyone can decode a JWT and read the payload. Base64URL decoding requires no key. Never put passwords, credit card numbers, or sensitive personal data in a JWT. The signature only proves the token hasn't been tampered with — it doesn't hide the content. Use JWT for user IDs, roles, and permissions — never for secrets.

Token expiry and the exp claim

The exp claim is a Unix timestamp indicating when the token expires. After this time, the server should reject the token regardless of whether the signature is valid. Short-lived tokens (15–60 minutes) combined with refresh tokens are the current security best practice. This tool shows the exact expiry time and how long until expiration or since expiration.

Frequently asked questions

Is it safe to paste my JWT here?
All decoding happens locally in your browser — your token is never sent to any server. That said, treat JWTs like passwords: avoid pasting production tokens from sensitive systems into any online tool. Use this tool for debugging tokens in development.
Can this tool verify the JWT signature?
No. Signature verification requires the secret key (for HMAC) or public key (for RSA/ECDSA), which only your server should have. This tool decodes and inspects the payload — it cannot verify authenticity.
Why is my JWT showing as expired?
The exp claim is a Unix timestamp for when the token expires. If the current time is past that timestamp, the token is expired. Your server should be issuing a new token via refresh token flow.
What algorithms do JWTs support?
Common algorithms: HS256/HS384/HS512 (HMAC with SHA), RS256/RS384/RS512 (RSA), ES256/ES384/ES512 (ECDSA). The algorithm is specified in the header's alg field. HS256 is most common for simple APIs; RS256 is preferred for distributed systems.
What is the difference between JWT and session tokens?
Session tokens are opaque strings stored server-side — the server looks up state in a database. JWTs are self-contained — all claims are in the token itself, so no database lookup is needed. JWTs are stateless and scale better; sessions are easier to invalidate.
How do I decode a JWT in JavaScript?
Split the token by "." to get three parts. Base64URL-decode the first two parts (replace - with + and _ with /), then JSON.parse the result. The third part is the signature and cannot be verified without the secret key.