Free JWT Decoder
Decode any JSON Web Token — split into header, payload and signature. View all claims with human-readable timestamps, check expiry status, and verify HS256, HS384 or HS512 signatures. All in your browser.
Your Token
Decoded Token
No token yet
Paste a JWT in the left panel to decode itWhat Is a JWT?
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe way to represent claims — statements about a subject — that are transferred between two parties. It is defined by RFC 7519 and is the default authentication mechanism for virtually every modern web API.
A JWT has three parts separated by dots:
| Part | Contents | Encoding |
|---|---|---|
| Header | Algorithm and token type | Base64url |
| Payload | Claims (user data, timestamps, roles) | Base64url |
| Signature | HMAC or RSA/ECDSA signature over header.payload | Base64url |
The full token looks like xxxxx.yyyyy.zzzzz — three Base64url segments joined by periods. Almost every JWT starts with eyJ, because the header is always a JSON object starting with the byte for {.
The header
The header is a small JSON object that describes the token itself. It typically contains two fields, and may contain more:
| Field | Meaning | Example |
|---|---|---|
| alg | Signing algorithm | HS256, RS256, ES256 |
| typ | Token type | JWT |
| kid | Key ID — which key was used | 2024-key-1 |
| cty | Content type (for nested JWTs) | JWT |
Standard claims (registered names)
RFC 7519 defines seven "registered" claim names that have defined meanings. Any other claim name is application-specific and free-form.
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Who created the token (often a URL) |
| sub | Subject | Who the token is about (usually a user ID) |
| aud | Audience | Who the token is intended for |
| 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 created |
| jti | JWT ID | Unique identifier for the token |
All three timestamp claims (exp, iat, nbf) are integers representing seconds since the Unix epoch. A common mistake is to mistake them for milliseconds — which makes the date come out as the year 56000-something.
Signing algorithms
| Family | Algorithms | Key type | Verification |
|---|---|---|---|
| HMAC | HS256, HS384, HS512 | Symmetric secret | ✅ Verifiable in this tool |
| RSA | RS256, RS384, RS512, PS256… | RSA public/private | ⚠️ Server-side |
| ECDSA | ES256, ES384, ES512 | EC public/private | ⚠️ Server-side |
| None | none | — | ❌ Insecure — never accept |
HMAC uses a shared secret, which is why this tool can verify it client-side: both sides hold the same key. RSA and ECDSA use a private key to sign and a public key to verify, so real verification requires importing the public key.
The critical distinction: decode ≠ verify
This is the single most important concept to understand about JWTs:
- Decoding reverses the Base64url encoding. Anyone can do it. It proves nothing. A tampered token will still decode without any error.
- Verifying recomputes the signature over
header.payloadusing the secret (or public key) and checks it matches. This is what proves the token was issued by someone holding the key, and that it has not been modified.
An attacker can freely change the payload of a JWT (for example, promote themselves from "role":"user" to "role":"admin"), and the token will still decode perfectly. Only signature verification on the server catches this. Never trust decoded claims without verifying them first.
Common use cases
Debug Auth Bugs
See exactly what claims your server issued in a session token.
Check Expiry
Confirm a token has not expired before wasting time on it.
Verify Signatures
Test that your server's HS256 secret produces the expected signature.
Inspect Roles
See which permissions and scopes a token carries.
Security Review
Spot insecure alg: none or weak algorithms in your pipeline.
Debug OAuth Flows
Trace the ID token returned by an OAuth or OIDC provider.
Inspect Webhook Tokens
Decode signed webhooks from Stripe, GitHub, Shopify and others.
Learn JWT Structure
See the header-payload-signature layout visually.
Privacy and security
This JWT decoder runs entirely in your browser. Decoding uses atob and TextDecoder, verification uses the native Web Crypto API. Nothing is uploaded, stored or transmitted — but remember that a JWT is a bearer credential. Anyone who holds it can use it. Treat pasting one into any tool as a security decision, even a client-side one, and prefer test tokens over production ones.
Frequently Asked Questions
What is a JWT?
Is this JWT decoder free?
Is my JWT sent to a server?
atob function, TextDecoder and the Web Crypto API. Your token never leaves your device — nothing is uploaded, stored or transmitted.Is decoding a JWT the same as verifying it?
What does the header contain?
alg (the algorithm used to sign the token, such as HS256, RS256 or ES256) and typ (the token type, almost always JWT). It may also contain kid (key ID) to indicate which key was used, and other metadata for specific implementations.What are the standard claims in the payload?
iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at) and jti (JWT ID). All timestamps are expressed as Unix seconds since the epoch. Any additional claim names are application-specific.Can I verify the signature in the browser?
Why does my token start with eyJ?
0x7B, which is a left curly brace. In Base64url that byte is always the first two characters ey, and the next two characters (J...) come from the rest of the typical header like {"alg":. Almost every JWT therefore begins with eyJ.