JSON Web Token (JWT) Decoder

What is a JSON Web Token (JWT) Decoder & Inspector?

A JSON Web Token (JWT) Decoder & Inspector is a critical security and API debugging tool that inspects, unpacks, and analyzes RFC 7519 JSON Web Tokens. JWT is an open standard that defines a compact, URL-safe means for securely transmitting claims between parties in modern web applications, microservices, and mobile apps.

A standard JSON Web Token consists of three distinct URL-safe Base64-encoded segments separated by periods (.):

1. Header: Specifies the cryptographic signing algorithm (such as HS256, RS256, or ES256), token type (JWT), and key identifiers (kid).
2. Payload: Contains the identity claims, user permissions, issuer details, subject identifiers, and authorization scopes.
3. Signature: The cryptographic signature generated using the issuer's private key or shared HMAC secret to ensure integrity.

Our inspector decodes the Header and Payload in your browser, converts Unix epoch timestamps into human-readable dates, verifies expiration status, and provides 100% private client-side debugging.

Why Software Developers & Security Engineers Need JWT Inspection

Decoding JWTs is a daily requirement across modern identity and authorization workflows:

• Debugging OAuth 2.0 & OpenID Connect (OIDC) Flows: Inspecting ID tokens and Access tokens issued by identity providers (Auth0, Okta, Firebase Authentication, AWS Cognito, Keycloak, Microsoft Entra ID).
• Checking Token Expiration (`exp`) & Refresh Cycles: Verifying whether an API 401 Unauthorized error was triggered by token expiration or missing scope permissions.
• Inspecting Role-Based Access Control (RBAC) & Scopes: Validating that user roles (admin, editor) and fine-grained OAuth scopes (read:reports, write:users) are correctly populated in the payload claims.
• Diagnosing Signing Algorithm Mismatches: Checking whether your backend API expects asymmetric RSA signatures (RS256) while the authorization server emitted symmetric HMAC tokens (HS256).

Step-by-Step JWT Decoding Example

The following real-world example illustrates how a compact encoded bearer token is decoded into its constituent Header and Payload JSON structures.

Input: Encoded JSON Web Token

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleV8yMDI2X3Byb2QifQ.eyJpc3MiOiJodHRwczovL2F1dGgvanNvbmVtcGlyZS5jb20vIiwic3ViIjoidXNyXzg0OTIwNCIsImF1ZCI6WyJodHRwczovL2FwaS5qc29uZW1waXJlLmNvbS92MSJdLCJleHAiOjE3NzA5ODg4MDAsIm5iZiI6MTczNTY4OTYwMCwiaWF0IjoxNzM1Njg5NjAwLCJ1c2VyIjp7Im5hbWUiOiJBZGEgTG92ZWxhY2UiLCJlbWFpbCI6ImFkYUBhbGdvcml0aG0ub3JnIiwicm9sZXMiOlsiQURNSU4iLCJBUkNISVRFQ1QiXX19.signature_preview_bytes

Output: Decoded Header JSON

{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "key_2026_prod"
}

Output: Decoded Payload Claims JSON

{
  "iss": "https://auth.jsonempire.com/",
  "sub": "usr_849204",
  "aud": [
    "https://api.jsonempire.com/v1"
  ],
  "exp": 1770988800,
  "_exp_human_readable": "Fri, 13 Feb 2026 13:20:00 GMT",
  "iat": 1735689600,
  "_iat_human_readable": "Wed, 01 Jan 2025 00:00:00 GMT",
  "user": {
    "name": "Ada Lovelace",
    "email": "ada@algorithm.org",
    "roles": [
      "ADMIN",
      "ARCHITECT"
    ]
  }
}

RFC 7519 Standard Registered Claims Reference

The table below outlines official registered claim keys defined in RFC 7519:

• iss (Issuer): Identifies the principal or authority that issued the JWT.
• sub (Subject): Identifies the user or resource principal that the token represents.
• aud (Audience): Identifies the recipients (APIs or microservices) that the JWT is intended for.
• exp (Expiration Time): Unix epoch timestamp identifying when the token expires and must be rejected.
• nbf (Not Before): Unix timestamp identifying the time before which the token must not be accepted.
• iat (Issued At): Unix timestamp identifying when the JWT was created.
• jti (JWT ID): Unique identifier for the token to prevent replay attacks.

Understanding Symmetric vs. Asymmetric Signing Algorithms

JWT signatures protect against client-side tampering:

• Symmetric Algorithms (`HS256`, `HS384`, `HS512`): Use a single shared secret key for both signing and verification. Suitable for closed architectures where only trusted backend servers verify tokens.
• Asymmetric Algorithms (`RS256`, `ES256`, `EdDSA`): The authorization server signs tokens using a private RSA or Elliptic Curve key, while resource APIs verify signatures using a public key published via a JWKS (JSON Web Key Set) endpoint (/.well-known/jwks.json).

Token Expiration & Clock Skew Tolerance

In distributed cloud environments, clock drift between the authorization server and microservices can cause premature token rejection.

• Clock Skew Tolerance: JWT validator libraries (such as jsonwebtoken in Node or System.IdentityModel.Tokens.Jwt in .NET) typically allow a 1 to 2 minute leeway (clock skew) when evaluating nbf (not before) and exp (expiration) claims.
• Short-Lived Access Tokens: Industry security standards recommend expiring Access Tokens within 15 to 60 minutes, paired with long-lived Refresh Tokens stored in secure HTTP-only cookies.

Mitigating the "alg: none" Signature Stripping Attack

The "alg": "none" vulnerability occurs when insecure backend validators accept unsigned tokens crafted by attackers who strip the signature and set the algorithm header to none:

• Always Whitelist Algorithms: Always explicitly configure your server's JWT validator to allow only expected algorithms (e.g. algorithms: ['RS256']).
• Reject Unsigned Tokens: Never allow dynamic algorithm selection derived directly from incoming unverified token headers.

100% Client-Side Privacy & Air-Gapped Security Guarantee

JSON Web Tokens frequently contain sensitive authentication credentials, private user identity claims, corporate email addresses, and API authorization scopes. Pasting tokens into cloud web tools is a severe security risk because malicious servers can intercept valid tokens and execute account takeovers.

JSON Empire guarantees zero data leakage:

• All Base64URL decoding, claim extraction, and timestamp formatting execute 100% locally on your computer's CPU.
• Zero HTTP network requests are made. No tokens, headers, or payload claims ever leave your web browser.
• Works completely offline and in air-gapped corporate environments.

Frequently Asked Questions

Does decoding a JWT verify its signature?

Decoding extracts and displays the human-readable claims stored in the token. Signature verification requires the issuer's private secret key or public JWKS certificate, which should be verified on your secure backend API.

Why does my token start with `Bearer `?

In HTTP headers, tokens are transmitted as Authorization: Bearer <token>. Our decoder automatically strips the Bearer prefix if present.

How can I download the decoded payload JSON?

Click the "💾 Download Payload" button in the workspace panel to save a standalone JSON file directly to your disk.