Online JWT Decoder & Inspector
Decode JSON Web Tokens in real-time. Inspect header metadata, payload claims, expiration countdowns, and signature algorithms with zero server tracking.
1. Understanding the JSON Web Token (JWT) Standard
A JSON Web Token (JWT) is an open industry standard specified under RFC 7519 that defines a compact, URL-safe container for transferring claims between two parties. Widely used across OAuth 2.0, OpenID Connect, serverless functions, and Single Page Application (SPA) authentication workflows, JWTs enable stateless authentication without querying session databases on every request.
While JWTs are cryptographically signed to prevent unauthorized payload tampering, their claims are encoded via Base64URL, not encrypted. Any client or intermediate party possessing the token string can decode the claims. Never store database passwords, plaintext secrets, or sensitive personal data inside a standard JWT payload.
2. Technical Architecture & Segment Breakdown
| Segment | Name | Encoding Format | Primary Function & Contents |
|---|---|---|---|
| Segment 1 | Header | Base64URL JSON | Identifies token type (JWT) and cryptographic signing algorithm (HS256, RS256) |
| Segment 2 | Payload | Base64URL JSON | Contains registered claims (sub, exp, iat) and application identity data |
| Segment 3 | Signature | Binary Hash / Crypto Signature | Validates that the token was issued by an authentic source and has not been altered |
3. Standard Registered Claims Reference
exp(Expiration Time): A Unix timestamp indicating when the token expires. Backend validation libraries must reject tokens after this time.iat(Issued At): A Unix timestamp recording when the authentication server minted the token.nbf(Not Before): A Unix timestamp identifying the earliest moment the token is valid for processing.sub(Subject): The unique identifier of the authenticated user or service principal.iss(Issuer): The authority or auth server domain that generated the token.aud(Audience): The designated recipient or backend API service for which the token was issued.
4. Client-Side Privacy Guarantee
All token parsing, Base64URL decoding, and expiration analysis run 100% locally in your web browser session using client-side JavaScript. Authentication tokens, API keys, and session identities are never transmitted across external networks or saved to remote databases.
5. Frequently Asked Questions
Why can anyone decode a JWT token?
JWTs are signed, not encrypted. The Base64URL encoding is used so that JSON structures can be safely transferred in HTTP headers and URLs. Signing ensures integrity (detecting tampering), while encryption (JWE) is required if data secrecy is needed.
What is the 'none' algorithm vulnerability?
The JWT specification includes an algorithm identifier named none for unsigned tokens. If backend verification libraries do not explicitly enforce signing algorithms, attackers can alter the payload, set "alg": "none", strip the signature, and bypass authentication.
Where should JWTs be stored in client web applications?
Storing JWTs in browser localStorage leaves them vulnerable to Cross-Site Scripting (XSS) attacks. Security best practice is to store session JWTs in HttpOnly, Secure, SameSite cookies, which cannot be accessed by client-side JavaScript.