JWT Decoder & Inspector

Instantly inspect and decode JSON Web Tokens (JWT) client-side. View headers, payload claims, and raw signatures with real-time validation and localized security analysis.

Loading JWT Decoder & Inspector workspace...

What is a JWT (JSON Web Token) Decoder?

Overview and core technical concepts

A JWT Decoder is an engineering tool that unpacks Base64URL encoded JSON Web Tokens into their constituent Header, Payload (Claims), and Signature segments without revealing private keys or executing network requests.

Unpacks RFC 7519 standard JWT structures
Decodes Header algorithm parameters (RS256, HS256, EdDSA)
Parses Claims (exp, nbf, iat, sub, iss, aud) into local timestamps
Calculates token expiration status and time remaining in real time
Technical Architecture:Splits tokens by periods (.), performs standard Base64URL decoding on headers and payload chunks, and evaluates UNIX timestamp claims against system clock drift.

Why Use a JWT Decoder?

Key advantages, developer speedups, and security benefits

Inspect Authentication Claims

Verify user IDs, scopes, granted permissions, and tenant roles embedded inside bearer tokens.

Debug Token Expiry Issues

Determine why APIs return 401 Unauthorized by checking exact exp (expiration) and nbf (not before) timestamps.

Validate Algorithm Standards

Ensure your authorization server is issuing strong cryptographic algorithms (RS256/ES256) instead of dangerous 'none' algorithms.

Zero Secret Exposure

Decoding token claims does not require your HMAC secret or RSA private key. The payload is public metadata.

When Shouldn't You Use a JWT Decoder?

Anti-patterns, limitations, and when to choose an alternative approach

Verifying Cryptographic Signatures Online

To cryptographically verify a JWT signature, your app must check public key certificates locally. Decoding claims alone does not verify token authenticity.

Storing Sensitive PII in Tokens

JWT payloads are Base64 encoded, NOT encrypted. Anyone who intercepts a JWT can read its contents. Never place passwords or SSNs inside JWT claims.

JWT Structure & Decoded Claims Example

Sample inputs, expected outputs, and code patterns

Standard OAuth2 Bearer Token

Deconstructing a standard identity token payload.

Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Expected Output
Header: {"alg": "HS256", "typ": "JWT"}

Payload: {
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Common JWT Security Mistakes

Frequent errors, security risks, and how to fix them

Confusing Base64URL Encoding with Encryption
The Mistake:Putting user passwords, API keys, or private tokens inside JWT payload fields.
The Impact:Anyone with access to HTTP headers or local storage can instantly decode the token and steal credentials.
How to Fix:Keep JWT payload claims minimal (user_id, roles, exp). Use JWE (JSON Web Encryption) if confidentiality is required.
Accepting Tokens with alg: 'none'
The Mistake:Allowing your backend JWT verification library to accept unsigned 'none' algorithm headers.
The Impact:Attackers can modify payload claims (e.g. change role from 'user' to 'admin') and strip the signature.
How to Fix:Explicitly enforce expected verification algorithms (e.g. verify with ['RS256']) in your backend code.

Frequently Asked Questions

A JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact, self-contained way for securely transmitting information between parties as a JSON object. Because it is digitally signed, the information can be verified and trusted. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Yes, absolutely. Unlike many online tools that send your token to their servers for parsing, ToolZeno's JWT Decoder runs 100% client-side inside your browser sandbox. The base64url decoding and JSON formatting are executed using your local JavaScript runtime. Your sensitive access tokens, claims, and keys are never transmitted over the internet or stored on a server.

This tool is designed to inspect and decode the contents of a JWT. To verify a signature, the tool would need access to your application's private key, public key, or shared secret key. Because sharing security keys online is a severe risk, this tool does not ask for your keys and does not attempt signature validation. To verify authenticity, you must perform signature verification inside your backend code using a secure library.

A standard JWT consists of three segments separated by dots (.): Header, Payload, and Signature. 1) The Header contains the token type (usually JWT) and the signing algorithm (e.g. HS256, RS256). 2) The Payload contains the claims, which are statements about an entity (typically a user) and additional metadata. 3) The Signature is generated using the encoded header, encoded payload, a secret key, and the specified algorithm, ensuring the token hasn't been altered.

Claims are pieces of information asserted about a subject (such as a user). Standard registered claims are pre-defined key names established by RFC 7519, such as 'iss' (Issuer), 'sub' (Subject), 'aud' (Audience), 'exp' (Expiration Time), 'nbf' (Not Before), 'iat' (Issued At), and 'jti' (JWT ID). Using these standard claims is highly recommended to ensure interoperability and secure defaults.