100% client-side  ·  your token never leaves this browser

Input — paste your JWT token

Header
Payload
Signature not verified client-side
Further reading: how to read a JWT token
All decoding is done in your browser. Your JWT token is never sent to any server.

How JWT Tokens Work

A JSON Web Token (JWT) is a compact, URL-safe way of representing claims between two parties. It is used extensively in authentication systems — when you log into a web app, the server often issues a JWT that your browser sends with every subsequent request to prove your identity.

A JWT has three parts separated by dots. The header contains metadata about the token type and signing algorithm. The payload contains the claims — data about the user and session like user ID, roles, and expiry time. The signature is a cryptographic hash of the header and payload, signed with a secret key, which allows the server to verify the token hasn't been tampered with. For encoding details, our Base64 Encoder handles the same Base64URL encoding that JWT uses internally.

Worked Example

A typical JWT (paste this into the tool above)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Common JWT Claims

The payload contains registered claims with standard meanings: sub (subject — usually the user ID), iss (issuer — who created the token), aud (audience — who the token is for), exp (expiration time as a Unix timestamp), iat (issued at time), and nbf (not before — token is invalid before this time). Custom claims like role or email are added by the application issuing the token. Use our JSON Formatter if you need to inspect complex nested payload structures.

Why the Signature Cannot Be Verified Client-Side

The signature is created using a secret key that only the server knows. To verify it, you would need that secret — which defeats the purpose of keeping it secret. This tool decodes the header and payload (which are only Base64URL encoded, not encrypted) and displays the raw signature string. Verification must happen server-side using the issuing service's public key or shared secret.


Frequently Asked Questions

Is it safe to paste my JWT token into an online decoder?
Yes, with this tool — all decoding runs entirely in your browser using JavaScript. Your token is never transmitted to any server. That said, treat JWTs like passwords: a valid token grants access to whatever it authorizes until it expires. Only paste tokens into tools you trust and can verify are client-side. If you believe a token has been compromised, revoke it immediately through your application's session management.
Can anyone decode a JWT without the secret key?
Yes — the header and payload of a standard JWT are only Base64URL encoded, not encrypted. Anyone who has the token string can decode and read its contents. The secret key is only needed to verify the signature — to confirm the token hasn't been tampered with. This is why you should never store sensitive data like passwords or credit card numbers in a JWT payload.
What's the difference between decoding and verifying a JWT?
Decoding reads the contents of the JWT — it just Base64URL-decodes the header and payload. Anyone can do this without any key. Verifying checks the signature to confirm the token was issued by who it claims and hasn't been modified. Verification requires the signing secret (for HS256) or the issuer's public key (for RS256/ES256). This tool decodes only — verification must happen server-side where the key is held securely.
Why does a JWT have three parts separated by dots?
The three parts are the header, payload, and signature — each Base64URL encoded and joined with dots. The header describes the token type and signing algorithm. The payload contains the claims (data). The signature is a cryptographic hash of the first two parts, signed with a secret key. The dot-separated format keeps the token compact and URL-safe, which matters because JWTs are often sent in HTTP headers or URL parameters. Use our Base64 Decoder to manually decode any individual part.
What do iat, exp, and nbf mean in a JWT payload?
These are registered claim names defined in the JWT specification. iat (Issued At) is the Unix timestamp when the token was created. exp (Expiration Time) is the Unix timestamp after which the token must be rejected — the server checks this on every request. nbf (Not Before) is a timestamp before which the token is not yet valid. All three use Unix time — seconds since January 1, 1970. This tool converts all three to human-readable dates and shows relative time (e.g. "Expires in 4h 22m").
How do I decode a JWT without an online tool?
Open your browser's DevTools console (F12), paste the following and replace YOUR_TOKEN with your JWT: JSON.parse(atob('YOUR_TOKEN'.split('.')[1].replace(/-/g,'+').replace(/_/g,'/'))). This Base64URL-decodes the payload part and parses it as JSON. For the header, use index [0] instead of [1]. The replace calls normalise Base64URL to standard Base64 before decoding.