JWT Decoder

Decode and inspect JSON Web Tokens — header, payload, and signature. Decoding only; no signature verification is performed.

Frequently Asked Questions

A JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information as a JSON object. It has three Base64URL-encoded parts separated by dots: Header (algorithm & token type), Payload (claims), and Signature. The signature is created using the chosen algorithm and a secret key held by the server.

No. The payload is only Base64URL-encoded, not encrypted. Anyone who holds the token can decode and read the claims. Never store sensitive data (passwords, credit card numbers) in a JWT payload unless you use JWE (JSON Web Encryption). The signature only proves the token hasn't been tampered with — it does not provide confidentiality.

A JWT has three Base64URL-encoded parts separated by dots. The Header is a JSON object containing the algorithm (alg, e.g. HS256) and token type (typ: "JWT"). The Payload contains claims — statements about the user and additional metadata. The Signature is computed by signing the encoded header and payload with the secret key using the specified algorithm — it allows the receiver to verify the token has not been tampered with.

Session tokens are opaque random strings — the server stores session data in a database or memory and looks up the session on every request. JWTs are stateless — all claims are embedded in the token itself, so the server can verify and read them without any storage lookup. This makes JWTs ideal for distributed systems and microservices where multiple servers need to authenticate requests without a shared session store. The tradeoff: JWTs cannot be instantly revoked (you must wait for expiry unless you implement a blocklist).

RFC 7519 defines these registered claims: iss (issuer — who created the token), sub (subject — who the token refers to, typically a user ID), aud (audience — intended recipient), exp (expiration time — Unix timestamp after which the token is invalid), nbf (not before — token not valid before this time), iat (issued at — when the token was created), and jti (JWT ID — unique identifier, useful for preventing replay attacks). All are optional but exp, iat, sub, and iss should always be included.

The standard pattern uses two tokens: a short-lived access token (typically 15 minutes to 1 hour) used to authenticate API requests, and a long-lived refresh token (days to weeks) stored securely and used only to obtain a new access token when the current one expires. The access token is kept short-lived to minimize the window of misuse if stolen. The refresh token can be revoked server-side (stored in a database), giving you a revocation mechanism that pure stateless JWTs lack.

HS256 (HMAC-SHA256) uses a single shared symmetric secret — both the issuer and every verifier must have the secret. Simple to implement but if the secret leaks any party can forge tokens. RS256 (RSA-SHA256) uses an asymmetric key pair — the issuer signs with a private key, verifiers check with the public key. Verifiers never need the private key, making RS256 better for multi-service architectures where multiple services verify tokens without being able to issue them. Use HS256 for single-server apps; use RS256 or ES256 for distributed systems.

The alg: "none" vulnerability occurs when a JWT library accepts tokens with no signature if the header specifies "alg":"none". An attacker can craft a token with any payload, set the algorithm to none, and omit the signature — a vulnerable library would accept it as valid. Always explicitly whitelist the accepted algorithms in your JWT library configuration and never accept none. Similarly, validate that the alg in the token header matches the expected algorithm — do not let the token dictate the verification method.

The safest option is an httpOnly, Secure, SameSite=Strict cookie — this prevents JavaScript from accessing the token, eliminating XSS theft. Storing JWTs in localStorage or sessionStorage is convenient but any XSS vulnerability on the page can steal them. Storing in a regular JavaScript-accessible cookie has the same XSS risk. The httpOnly cookie approach does introduce CSRF risk, which is mitigated by the SameSite attribute and custom CSRF tokens. For most web apps, httpOnly cookies are the recommended choice.

JWT (self-contained token): contains all claims inline, verified without database lookup, ideal for stateless microservices. Downside: cannot be instantly revoked before expiry without a blocklist. Opaque tokens: random strings with no intrinsic meaning, the server looks up the token in a database to retrieve associated data. Instantly revocable (just delete the database row), but every request requires a database or cache lookup. Choose JWTs when scalability and statelessness are priorities; choose opaque tokens when instant revocation is a hard requirement (e.g., financial applications).

About This JWT Decoder

This free JWT decoder splits a JSON Web Token into its three parts — header, payload, and signature — and displays each section as readable JSON. The token is decoded entirely in your browser; no data is sent to a server.

JWTs are Base64URL-encoded and used to transmit identity claims between services. Inspecting the payload is a common debugging task when troubleshooting authentication failures, token expiry issues, or unexpected permission errors.

When to use this tool

  • Inspecting claims in an access token or ID token
  • Checking token expiry (exp) and issued-at (iat) timestamps
  • Verifying the signing algorithm (alg) in the header
  • Debugging OAuth 2.0 and OpenID Connect authentication flows

How JWT Decoding Works

A JSON Web Token is three Base64URL-encoded segments joined by dots. Decoding is pure client-side — no network request is needed.

Split on Dots

The token is split at each . character into exactly 3 parts: the header, the payload, and the signature. A valid JWT always has exactly 2 dots — any other count is immediately rejected.

Base64URL Decode

Each part uses Base64URL encoding: - replaces + and _ replaces /, with = padding omitted. The header and payload are decoded to UTF-8 JSON strings and parsed.

Interpret Claims

Standard claims (exp, iat, nbf, sub, iss, aud) are recognized and displayed with human-readable labels. Unix timestamps are converted to readable date strings.

No verification: This tool only decodes. The signature is shown raw but is not verified. Never trust JWT claims in production without server-side signature verification using the correct secret or public key.

Common Use Cases

Auth Flow Debugging

When building or debugging OAuth 2.0, OpenID Connect, or custom JWT auth, paste the access or ID token here to instantly inspect the algorithm, issuer, audience, expiry, and all custom claims.

Token Expiry Check

The tool shows a live expiry countdown from the exp claim. Useful when a user reports intermittent 401 errors — quickly see if the token is about to expire or has already expired.

User Claim Inspection

OpenID Connect ID tokens include user information such as email, name, roles, and groups. Decode the token to verify the correct claims are present after a login flow.

Verifying Token Structure

Before implementing JWT verification in a new language or framework, check that the token's alg header matches the expected algorithm (e.g., RS256 vs HS256) to avoid algorithm confusion vulnerabilities.

Third-Party Token Review

Third-party services (AWS Cognito, Auth0, Firebase, Okta) issue JWTs for their APIs. Decode them to understand the payload structure before building an integration, without needing their SDK.

Learning JWT Internals

Use the tool together with the Base64 Encoder/Decoder to manually decode a JWT segment-by-segment and understand exactly how the format works at the byte level.

Related Articles

View all articles
JWT vs Opaque Session Tokens: Why This Tool Can Decode Some Tokens and Not Others

JWT vs Opaque Session Tokens: Why This Tool Can Decode Some Tokens and Not Others

Some APIs return a token that decodes into readable claims; others return an opaque string that reveals nothing. The difference isn't a quality signal — it's the fundamental architectural choice between stateless JWTs (the token contains the session data) and stateful opaque tokens (the token is a lookup key into a server-side session store). Here's why instant revocation pushes some systems toward the "extra database lookup" approach, and what it means when a token you paste into this tool decodes to nothing.

Jun 14, 2026
JWT Token Refresh Strategies: Access Tokens, Refresh Rotation, and When Sessions Beat JWTs

JWT Token Refresh Strategies: Access Tokens, Refresh Rotation, and When Sessions Beat JWTs

Short-lived access tokens require a refresh mechanism — and how you implement that mechanism determines your app's security and user experience. Here's refresh token rotation, silent refresh in SPAs, theft detection via refresh token families, and the cases where server-side sessions are simpler and safer.

Jun 13, 2026
JWT Security Vulnerabilities: alg:none, Algorithm Confusion, and Secure Token Storage

JWT Security Vulnerabilities: alg:none, Algorithm Confusion, and Secure Token Storage

The alg:none attack, RS256/HS256 algorithm confusion, weak HS256 secrets, localStorage vs httpOnly cookies, and revocation without statefulness — JWT security vulnerabilities are specific and avoidable. Here's how each one works and how to fix it.

Jun 9, 2026
JWT Decoder — Debug Authentication Errors by Inspecting Token Claims

JWT Decoder — Debug Authentication Errors by Inspecting Token Claims

Learn how to use a JWT decoder to debug 401 errors, understand the header, payload, and signature sections, check expiry and audience claims, and identify security issues like alg:none attacks.

Jun 7, 2026
JWT Decoder — Inspect Any JSON Web Token Instantly

JWT Decoder — Inspect Any JSON Web Token Instantly

Learn what's inside a JSON Web Token, how to read the header, payload, and expiration claims, and how to use a free JWT decoder to debug authentication issues instantly.

Jun 6, 2026