JWT Decoder — Decode, Inspect & Debug JSON Web Tokens Online
Need to decode and inspect a JSON Web Token (JWT) quickly? This JWT Decoder parses the three parts of any JWT — header, payload, and signature — and displays them as formatted JSON. All processing happens entirely in your browser with no data uploaded to any server.
Whether you are debugging OAuth authentication flows, inspecting API tokens, or learning how JWTs work, this tool gives you instant visibility into token contents.
What Is a JWT?
A JSON Web Token (JWT) is a compact, URL-safe token format defined by RFC 7519. It is widely used for authentication and authorization in modern web applications, APIs, and microservices architectures.
JWTs are self-contained — they carry all the information needed to authenticate a user or verify a claim, eliminating the need for server-side session storage.
JWT Structure
Every JWT consists of three Base64-encoded parts separated by dots:
header.payload.signature
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
The Three Parts of a JWT
1. Header
The header contains metadata about the token — typically the signing algorithm and token type.
{
"alg": "HS256",
"typ": "JWT"
}Common header fields:
| Field | Description |
|---|---|
alg |
Signing algorithm (HS256, RS256, ES256, EdDSA) |
typ |
Token type (usually JWT) |
kid |
Key ID — identifies which key was used to sign |
cty |
Content type (for nested JWTs) |
2. Payload
The payload contains claims — statements about the user or entity and additional metadata.
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516242622
}Standard registered claims:
| Claim | Full Name | Description |
|---|---|---|
iss |
Issuer | Who created and signed the token |
sub |
Subject | The subject of the token (usually a user ID) |
aud |
Audience | Intended recipient of the token |
exp |
Expiration | Unix timestamp when the token expires |
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 for the token |
3. Signature
The signature is created by signing the Base64-encoded header and payload with a secret or private key. It ensures the token has not been tampered with.
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)
Common JWT Signing Algorithms
Symmetric Algorithms (Single Secret)
| Algorithm | Description | Key Size |
|---|---|---|
| HS256 | HMAC with SHA-256 | 256+ bits |
| HS384 | HMAC with SHA-384 | 384+ bits |
| HS512 | HMAC with SHA-512 | 512+ bits |
Symmetric algorithms use the same key to sign and verify. Best for single-service applications.
Asymmetric Algorithms (Key Pair)
| Algorithm | Description | Key Size |
|---|---|---|
| RS256 | RSA with SHA-256 | 2048+ bits |
| RS384 | RSA with SHA-384 | 2048+ bits |
| RS512 | RSA with SHA-512 | 2048+ bits |
| ES256 | ECDSA with P-256 | 256 bits |
| ES384 | ECDSA with P-384 | 384 bits |
| ES512 | ECDSA with P-521 | 521 bits |
| EdDSA | Edwards-curve DSA | 256 bits |
Asymmetric algorithms use a private key to sign and a public key to verify. Ideal for distributed systems and third-party integrations.
Decoding vs Validation
Decoding
Decoding Base64-decodes the three parts of a JWT and displays them as JSON. Anyone with a Base64 decoder can read the contents of a JWT — JWTs are not encrypted.
Validation
Validation goes further by:
- Verifying the cryptographic signature using the issuer's public key or shared secret
- Checking the expiration (
exp) claim against the current time - Validating the not before (
nbf) claim - Confirming the issuer (
iss) and audience (aud) - Checking for token revocation (via key ID or token blacklist)
Important: This tool decodes JWT contents but does not perform cryptographic signature validation. For that, you need the issuer's public key or shared secret.
JWT vs JWE
| Feature | JWT (JSON Web Token) | JWE (JSON Web Encryption) |
|---|---|---|
| Content visibility | Signed, not encrypted | Encrypted |
| Readable without key | Yes (Base64 decode) | No |
| Purpose | Authentication, authorization | Secure data exchange |
| Structure | header.payload.signature | Five parts (encrypted) |
Practical Examples
Example 1: Decoding a Simple JWT
JWT:
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjMsInJvbGUiOiJhZG1pbiJ9.Hx9fFg
Header:
{
"alg": "HS256"
}Payload:
{
"user_id": 123,
"role": "admin"
}Example 2: OAuth2 Access Token
{
"iss": "https://auth.example.com",
"sub": "user_abc123",
"aud": "https://api.example.com",
"exp": 1735689600,
"iat": 1735603200,
"scope": "read write",
"client_id": "my-client"
}Example 3: ID Token with User Profile
{
"iss": "https://accounts.google.com",
"sub": "1234567890",
"email": "user@example.com",
"email_verified": true,
"name": "Jane Smith",
"picture": "https://example.com/photo.jpg",
"given_name": "Jane",
"family_name": "Smith",
"iat": 1516239022,
"exp": 1516242622
}Use Cases for JWT Debugging
OAuth2 and OpenID Connect Flows
Inspect the ID token and access token returned by identity providers like Auth0, Okta, Keycloak, or Firebase Authentication. Verify that the correct claims are present.
API Authentication Debugging
When an API returns a 401 Unauthorized, decode the token to check expiration, audience, and issuer claims. This is often faster than digging through logs.
Microservices Authorization
Debug tokens passed between internal services through API gateways, service meshes, or message queues. Verify that service-to-service tokens carry the correct roles and permissions.
CI/CD Pipeline Token Testing
Inspect tokens generated during automated testing and deployment to ensure they have the correct format and claims.
JWT Library Development
When implementing JWT creation or verification in a new programming language, use the decoder to verify your library produces correctly structured tokens.
Security Considerations
JWTs Are Not Encrypted
Anyone with the token can Base64-decode the header and payload. Never store sensitive data (passwords, credit card numbers, personal secrets) in a JWT payload.
Verify on the Server Side
Always validate the signature and expiration on the server before trusting any JWT. Client-side decoding is for debugging only.
Use HTTPS
Always transmit JWTs over HTTPS to prevent interception. A stolen token can be used to impersonate the user until it expires.
Protect Your Signing Keys
- For HS256: Keep the shared secret secure and rotate it regularly
- For RS256/ES256: Protect the private key; distribute the public key
- Use environment variables or secrets managers, never hardcode keys
Short Expiration Times
Use short token expiration times (15-60 minutes) and implement token refresh to limit the damage from token theft.
Beware of the "none" Algorithm Attack
Some JWT libraries have been vulnerable to attacks where the algorithm is changed to none. Always validate that the algorithm matches the expected value.
JWT FAQs
Is my data uploaded to a server when using the JWT Decoder?
No. All processing happens 100% in your browser. Your data never leaves your computer, making this tool completely private and secure for sensitive information.
What is the difference between JWT and JWE?
JWT (JSON Web Token) is a signed token whose payload is Base64-encoded, not encrypted — anyone can decode it. JWE (JSON Web Encryption) is encrypted, meaning only the intended recipient can read the contents. This tool decodes JWTs and does not handle JWE.
What is the difference between RS256 and HS256?
HS256 (HMAC with SHA-256) uses a single shared secret for both signing and verification — both parties must know the secret. RS256 (RSA with SHA-256) uses a private key to sign and a public key to verify, making it more secure for distributed systems.
Can this tool validate JWT signatures?
This tool decodes the JWT and displays its three parts (header, payload, signature) but does not perform cryptographic signature validation. For signature verification, you need the issuer's public key or shared secret.
What is the difference between JWT decoding and JWT validation?
Decoding simply Base64-decodes the three parts of a JWT to human-readable JSON. Validation goes further by verifying the cryptographic signature, checking the expiration (exp) and not-before (nbf) claims, validating the issuer (iss) and audience (aud), and ensuring the token has not been tampered with.
What does a JWT payload typically contain?
A JWT payload contains claims — statements about an entity and additional metadata. Common registered claims include iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Custom claims may include user roles, permissions, or application-specific data.
How do I check if a JWT token is expired?
Look for the exp (expiration) claim in the decoded payload. It contains a Unix timestamp. Compare it with the current time — if the expiration time has passed, the token is expired. Some decoders highlight expired tokens automatically.
What is the structure of a JWT?
A JWT consists of three Base64-encoded parts separated by dots: header.payload.signature. The header typically specifies the signing algorithm and token type. The payload contains the claims. The signature is created by signing the encoded header and payload with the issuer's secret or private key.
Can this tool decode malformed JWT input?
The JWT Decoder handles standard encoded input correctly. If the input is malformed or contains invalid Base64 characters, the tool provides clear error messages to help you identify and fix the issue.
What algorithms are commonly used with JWTs?
Common signing algorithms include HS256 (HMAC with SHA-256), HS384, HS512, RS256 (RSA with SHA-256), RS384, RS512, ES256 (ECDSA with P-256), ES384, ES512, and EdDSA (Edwards-curve Digital Signature Algorithm). The algorithm is specified in the header's alg field.
Is it safe to share a decoded JWT?
No. While JWT payloads are not encrypted, they can contain sensitive information such as user IDs, email addresses, roles, and permissions. Even though the content is Base64-encoded (not encrypted), sharing the decoded contents could expose private information.
What is the kid field in a JWT header?
The kid (Key ID) field in the JWT header indicates which key was used to sign the token. This is useful when an issuer rotates keys — the kid tells the verifier which public key from a set to use for signature verification.
Related Tools
- JWT Generator — Create and sign JWTs for testing
- Base64 Decoder — Decode Base64 strings (useful for inspecting individual parts)
- Online JSON Formatter — Format and validate JSON payloads
- Hash Generator — Generate HMAC and other hash values
- RSA Key Pair Generator — Generate RSA keys for RS256 signing
- API Testing Tools — Test authenticated API endpoints with JWTs
Decode, inspect, and debug your JWT tokens instantly — all in your browser with complete privacy.