100% PRIVATE • IN-BROWSER PARSING • ZERO SERVER LOGS

Free Online JWT Token Decoder & Claims Inspector

Decode, inspect, and verify JSON Web Tokens (RFC 7519) with instant claim translation, live token expiration countdown, security vulnerability auditing (alg: none, weak secrets, sensitive keys), and client-side HMAC signature verification.

Paste or type a JSON Web Token below to inspect its header, claims, and signature. Decoding happens entirely in your local browser using client-side JavaScript.
Encoded Token Header . Payload . Signature
0 characters 0 segments Processed locally in memory
Cryptographic Signature Verification
Awaiting Secret
Algorithm detected: None (HMAC algorithms verified locally via Web Crypto API)
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
Decoded Header Algorithm & Token Type
// Header will be displayed here
Decoded Payload Data & Claims
Claim Key Value Human-Readable Description
No token decoded yet. Paste a token on the left or click "Load Sample" to begin.
// Payload claims will be displayed here

Complete Guide to JSON Web Tokens (JWT) & Claims

1. The Header

The header specifies the token type (usually "JWT") and the cryptographic signing algorithm (such as HS256, RS256, or ES256). It may also include key identifiers (kid) pointing to public keys in JWKS endpoints.

2. The Payload (Claims)

The payload contains assertions and claims about an entity (user, tenant, application) and metadata. Standard claims (iss, sub, aud, exp) coexist with custom authorization claims such as enterprise role groups and OAuth2 scopes.

3. The Signature

The signature is created by encoding the header and payload, joining them with a period, and signing the hash with a private key or symmetric secret. It ensures the token has not been tampered with in transit.

Crucial Difference: Encoding vs. Encryption

A standard JWT is encoded with Base64URL, NOT encrypted (unless using JWE - JSON Web Encryption). Anyone who intercepts a plain JWT can decode and read all claims inside the payload. Never store passwords, database connection strings, social security numbers, or sensitive credentials inside standard JWT claims.

Frequently Asked Questions

Yes, 100%. This tool operates entirely inside your local browser using client-side JavaScript. No tokens, payload claims, or signing secret keys are ever transmitted over the network or saved to any server. Your sensitive tokens remain strictly within your device's memory.
The alg: "none" vulnerability occurs when a server's JWT validation library blindly accepts tokens whose header specifies no algorithm and omits the signature segment. An attacker can craft a token with administrative privileges (e.g. role: "admin") without knowing the secret key. Our security audit panel immediately flags any token where the algorithm is set to none or the signature is missing.
Modern web browsers include the W3C Web Crypto API (window.crypto.subtle). For symmetric HMAC algorithms (HS256, HS384, HS512), this tool imports your secret key into your browser's cryptographic engine, computes the HMAC digest of base64url(header) + "." + base64url(payload), and verifies if it matches the token's signature byte-for-byte.
ASP.NET and Microsoft IdentityModel historically map standard JWT claims to WS-Federation/SAML claim types (such as http://schemas.microsoft.com/ws/2008/06/identity/claims/role for roles and http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier for user ID). Our Claims Inspector automatically identifies these long URIs and displays friendly, readable badges and definitions.