Instantly decode JWTs from Auth0, Firebase, AWS Cognito, and any provider. View claims, check expiration, and generate parsing code—all 100% in your browser.
Works offline. No data ever sent to servers.
A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact, self-contained way to securely transmit information between parties as a JSON object. JWTs are digitally signed using a secret (HMAC) or a public/private key pair (RSA or ECDSA), which means the information can be verified and trusted.
JWTs are widely used for authentication (access tokens, ID tokens) and authorization (passing user roles and permissions). When a user logs in, the authentication server issues a JWT containing user claims. The client stores this token and sends it with subsequent requests. Services can verify the token without contacting the auth server, making JWTs ideal for microservices and distributed systems.
Header
Algorithm & Token Type
Payload
Claims (User Data)
Signature
Verification Hash
The header typically consists of two parts: the token type (JWT) and the signing algorithm (e.g., HS256, RS256, ES256).
{
"alg": "RS256",
"typ": "JWT",
"kid": "key-id-123"
}Contains the claims—statements about the user (subject, email, roles) and metadata (issuer, expiration, audience).
{
"sub": "user-123",
"email": "user@example.com",
"exp": 1735689600,
"iss": "auth.example.com"
}Created by signing the encoded header and payload with a secret or private key. Used to verify the token wasn't tampered with.
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret )
These registered claim names are defined in the JWT specification and have specific meanings. While all claims are optional, using standard claims ensures interoperability.
| Claim | Full Name | Description | Example |
|---|---|---|---|
| iss | Issuer | Identifies who issued the JWT. Usually a URL or identifier of your auth server. | "https://auth.example.com" |
| sub | Subject | Identifies the principal (usually user ID). Should be unique within the issuer context. | "user_123456" |
| aud | Audience | Intended recipient(s) of the JWT. Can be a string or array of strings. | "https://api.example.com" |
| exp | Expiration Time | Unix timestamp after which the token MUST NOT be accepted. Critical for security. | 1735689600 |
| nbf | Not Before | Unix timestamp before which the token MUST NOT be accepted. | 1735600000 |
| iat | Issued At | Unix timestamp when the token was issued. Useful for determining token age. | 1735600000 |
| jti | JWT ID | Unique identifier for the token. Used to prevent replay attacks. | "a1b2c3d4-e5f6-7890" |
Choosing the right algorithm depends on your architecture. Symmetric algorithms (HS*) use a shared secret, while asymmetric algorithms (RS*, ES*, PS*) use public/private key pairs.
| Algorithm | Type | Description | Best For |
|---|---|---|---|
| HS256 | Symmetric | HMAC with SHA-256. Shared secret for sign & verify. | Simple apps, internal services |
| HS384 | Symmetric | HMAC with SHA-384. Stronger hash than HS256. | Higher security symmetric needs |
| HS512 | Symmetric | HMAC with SHA-512. Strongest HMAC option. | Maximum symmetric security |
| RS256 | Asymmetric | RSA with SHA-256. Private key signs, public verifies. | OAuth/OIDC, distributed systems |
| RS384 | Asymmetric | RSA with SHA-384. Stronger than RS256. | Enterprise applications |
| RS512 | Asymmetric | RSA with SHA-512. Strongest RSA option. | High-security enterprise |
| ES256 | Asymmetric | ECDSA with P-256 curve. Compact signatures. | Mobile apps, IoT devices |
| ES384 | Asymmetric | ECDSA with P-384 curve. Stronger than ES256. | Government, financial apps |
| PS256 | Asymmetric | RSA-PSS with SHA-256. Probabilistic padding. | Modern high-security apps |
When users report "401 Unauthorized" errors, decode their JWT to check if it's expired, has the wrong audience, or is missing required claims.
Inspect tokens during API development to verify your auth server is including the correct claims, scopes, and permissions.
Review what data is being transmitted in tokens. Check for sensitive PII, verify appropriate token lifetimes, and ensure secure algorithms are used.
Understand how JWTs work by decoding real tokens. Great for onboarding new developers or learning about OAuth/OIDC authentication flows.
JWT tokens often contain sensitive information: user IDs, email addresses, roles, permissions, and sometimes API keys or session identifiers. Many popular JWT tools (including jwt.io) transmit your tokens to their servers for processing.
Our decoder is 100% client-side. All parsing happens in your browser using JavaScript. Your tokens are never transmitted anywhere—you can verify this by checking your browser's Network tab while using the decoder. You can even disconnect from the internet after loading the page and continue decoding tokens.