JWT Decoder Online

JWT Decoder: Free Online JSON Web Token Inspector, Debugger, and Validator

JSON Web Tokens (JWTs) are the dominant mechanism for authentication and authorization in modern web applications, REST APIs, mobile backends, and microservices. They power OAuth 2.0 flows, OpenID Connect identity layers, machine-to-machine service authentication, and single sign-on systems used by millions of applications worldwide. When something breaks "” a 401 Unauthorized response, an expired token error, a missing claim, a mismatched audience "” you need to see inside the token immediately to diagnose the problem.

Our free JWT decoder lets you paste any JWT string and instantly view the decoded header, payload, and signature in human-readable JSON format. The tool converts Unix timestamps to readable dates, flags expired tokens, identifies the signing algorithm, highlights known security concerns, and lets you inspect every claim without sending any data to a remote server. Everything runs locally in your browser using JavaScript "” your tokens stay completely private.

Whether you are a backend engineer debugging a 401 response at midnight, a security engineer auditing token configuration, a frontend developer inspecting what claims are available after login, or a student learning about JWT-based authentication systems for the first time, this tool gives you the clarity you need instantly.

What Is a JSON Web Token (JWT)?

A JSON Web Token is a compact, URL-safe string that encodes claims "” assertions about a subject "” in a format that can be cryptographically verified. The JWT specification is defined in RFC 7519 by the Internet Engineering Task Force (IETF) and has become the de facto standard for stateless authentication in distributed systems.

A JWT is structured as three Base64URL-encoded segments separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The three segments are:

• Header "” a JSON object specifying the token type (typ) and the cryptographic algorithm (alg) used to sign it
• Payload "” a JSON object containing claims: assertions about the subject and additional metadata relevant to the application
• Signature "” a cryptographic value computed from the encoded header, the encoded payload, and a secret or private key, used to verify integrity

The compact dot-separated format was designed specifically to be safe in URL query parameters, HTTP Authorization headers, and cookie values without additional encoding. Base64URL differs from standard Base64 in that it replaces + with - and / with_, and omits padding characters, making it fully URL-safe.

Anatomy of the JWT Header

The JWT header is a Base64URL-encoded JSON object that acts as metadata about the token itself. At minimum it contains the alg field specifying the signing algorithm. A typical header looks like:

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

The typ (Type) field is almost always "JWT", distinguishing JSON Web Tokens from other token types. In some advanced scenarios involving JWEs (JSON Web Encryption) or nested JWTs, the type may be "JWE" or another value.

The alg (Algorithm) field is critical for security. It tells the receiving party which algorithm to use when verifying the signature. The supported algorithms under the JSON Web Algorithms (JWA) specification defined in RFC 7518 are:

Symmetric Algorithms (HMAC)

HMAC-based algorithms use a single shared secret for both signing and verification. They are appropriate when all parties that need to verify the token are trusted and can securely access the same secret:

• HS256 "” HMAC with SHA-256, the most widely used JWT signing algorithm
• HS384 "” HMAC with SHA-384, stronger but rarely needed
• HS512 "” HMAC with SHA-512, maximum HMAC strength

Asymmetric Algorithms (RSA)

RSA algorithms use a private key for signing and a public key for verification. The private key is kept secret by the issuer; the public key can be distributed freely to any service that needs to verify tokens:

• RS256 "” RSA PKCS#1 v1.5 signature with SHA-256
• RS384 "” RSA PKCS#1 v1.5 signature with SHA-384
• RS512 "” RSA PKCS#1 v1.5 signature with SHA-512
• PS256 "” RSA-PSS signature with SHA-256 (more secure padding than PKCS#1)
• PS384 "” RSA-PSS signature with SHA-384
• PS512 "” RSA-PSS signature with SHA-512

Asymmetric Algorithms (ECDSA)

Elliptic Curve Digital Signature Algorithm provides equivalent security to RSA with significantly smaller key sizes, making it ideal for constrained environments and high-throughput systems:

• ES256 "” ECDSA with P-256 curve and SHA-256
• ES384 "” ECDSA with P-384 curve and SHA-384
• ES512 "” ECDSA with P-521 curve and SHA-512

The Dangerous "none" Algorithm

The none algorithm specifies an unsigned token "” there is no signature. This value exists in the specification for situations where integrity is guaranteed by other means, but in practice it has been the source of severe security vulnerabilities. Several early JWT libraries accepted none tokens without checking, allowing attackers to craft arbitrary tokens with any claims they chose. Always explicitly specify allowed algorithms in your JWT library configuration and categorically reject none.

The kid (Key ID) Header Claim

The kid header parameter is an optional identifier for the signing key used. When a server rotates signing keys "” which should happen regularly for security "” it publishes multiple public keys in a JSON Web Key Set (JWKS). The kid in the JWT header tells verifiers which key to use for validation, allowing smooth key rotation without invalidating all existing tokens simultaneously. Our decoder displays the kid value prominently to help diagnose key rotation issues.

Anatomy of the JWT Payload: Claims Deep Dive

The payload is where the meaningful data lives. RFC 7519 defines three categories of claims: registered claims (standardized by the spec), public claims (registered in the IANA JSON Web Token Claims registry), and private claims (application-specific, agreed upon by parties).

Registered Claims: The Seven Standard Fields

These seven claim names are reserved and have specific semantic meanings defined by the specification. All are optional but widely used:

iss "” Issuer

The iss claim identifies the principal that issued the JWT. It is typically the URL of the authorization server: https://auth.example.com,https://accounts.google.com, or https://your-tenant.auth0.com/. Resource servers must validate that the issuer matches the expected authority. An incorrect or missing iss should cause the token to be rejected immediately.

sub "” Subject

The sub claim is the unique identifier for the principal the token represents "” almost always a user ID. It should be locally unique within the issuer context and stable for the lifetime of the account. Do not use mutable values like email addresses as the subject "” users can change their email but their ID should be permanent.

aud "” Audience

The aud claim identifies the intended recipients of the JWT "” the services or applications that are allowed to accept and use it. It can be a string or an array of strings. Resource servers must verify that their own identifier appears in the audience claim before processing the token. Audience validation prevents token confusion attacks where a token issued for Service A is presented to Service B.

exp "” Expiration Time

The exp claim is a Unix timestamp (seconds since January 1, 1970 UTC) after which the token must not be accepted for processing. This is the single most frequently misconfigured claim and the number-one cause of "valid-looking but rejected" tokens. Our decoder converts the raw numeric timestamp to a human-readable date and time in both UTC and local time, and tells you whether the token is currently expired, how long ago it expired, or how long until it expires.

Short-lived access tokens (15 minutes to 1 hour) dramatically limit the damage from token theft. Use refresh tokens for maintaining long-lived sessions rather than issuing long-lived access tokens.

nbf "” Not Before

The nbf claim is a Unix timestamp before which the token must not be accepted. It is less commonly used than exp but useful for tokens that should only become valid at a future time "” for instance, a scheduled batch job token that should not be usable until the scheduled start time.

iat "” Issued At

The iat claim records when the token was issued as a Unix timestamp. Together withexp, it defines the token's lifetime. It is also useful for detecting tokens that pre-date a password change or account compromise event "” if a user resets their password, any token with an iat before the reset time should be invalidated.

jti "” JWT ID

The jti claim is a unique identifier for the specific JWT instance, similar to a nonce. It enables token blocklisting and replay prevention: once a single-use token has been consumed, its jti is stored and any subsequent presentation of a token with the same jti is rejected. The JTI value must be unique per token and per issuer.

Common Private Claims in Practice

Beyond registered claims, real-world JWTs typically carry application-specific data:

• email "” the user's email address (OIDC profile scope)
• name / given_name / family_name "” user display name components (OIDC)
• picture "” URL to the user's profile photo (OIDC)
• scope "” space-separated OAuth 2.0 permissions granted to the bearer
• role / roles "” RBAC roles assigned to the user
• permissions "” fine-grained permission list (Auth0 RBAC)
• tenant_id / org_id "” multi-tenant application identifiers
• azp "” Authorized Party, the client that was issued the token
• sid "” Session ID for front-channel logout support
• nonce "” value bound to the OIDC authorization request to prevent replay
• at_hash / c_hash "” hash values binding the ID token to an access token or code

JWT Signature: Integrity Without Secrecy

The signature is computed by taking the Base64URL-encoded header, concatenating a dot, concatenating the Base64URL-encoded payload, and applying the signing algorithm with the secret or private key. For HS256:

HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)

For RS256:

RSA-SHA256-Sign(base64url(header) + "." + base64url(payload), privateKey)

The signature prevents tampering: if an attacker modifies any bit of the header or payload and recomputes Base64URL encoding, the signature will no longer match because they do not have the signing key. Note that the payload is encoded, not encrypted "” anyone who has the JWT can read the claims. Never put sensitive data like passwords, SSNs, or credit card numbers in a JWT payload.

Decoding vs Verifying: A Critical Distinction

Our decoder shows you the contents of the JWT header and payload by reversing the Base64URL encoding. This operation requires no secret and no key "” any party can decode any JWT. This is by design: the payload is not a secret; it is a set of claims that can be read by anyone who receives the token.

Verification is an entirely different operation. It uses the secret key (for HMAC) or public key (for RSA/ECDSA) to recompute the expected signature and compare it against the provided signature. If they match, the token was genuinely issued by the holder of the key and has not been altered. Only after successful verification should any application trust the claims in the payload.

Our tool optionally performs signature verification for RS256 and ES256 tokens using the Web Crypto API entirely in your browser. Paste a public key or JWKS JSON alongside the token to verify it client-side. For HS256 verification, you can optionally provide your secret "” it never leaves your browser.

JSON Web Key Sets (JWKS) and Key Rotation

Major identity providers publish their public signing keys at a well-known JWKS URL:

• Google: https://www.googleapis.com/oauth2/v3/certs
• Microsoft: https://login.microsoftonline.com/common/discovery/v2.0/keys
• Auth0: https://your-tenant.auth0.com/.well-known/jwks.json

A JWKS is a JSON object containing an array of JSON Web Keys (JWK). Each key has properties including kty (key type: RSA, EC, oct), kid (key ID matching the JWT header), use (sig for signing, enc for encryption), and the key material itself (n and e for RSA, x and y for EC).

Key rotation is a security best practice: regularly replace the signing key pair so that even if an old key is compromised, exposure is limited. The rotation process: (1) generate new key pair; (2) add new public key to JWKS alongside old key; (3) start signing new tokens with new private key; (4) wait for all tokens signed with old key to expire; (5) remove old public key from JWKS. The kid header claim makes this process seamless "” verifiers look up the right key by ID rather than needing to know which key is current.

JWT in OAuth 2.0 and OpenID Connect

OAuth 2.0 is an authorization framework defining how applications obtain delegated access to resources on behalf of users. OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0 that standardizes user authentication.

In an OIDC flow, the identity provider returns two tokens: an access token for calling APIs (often a JWT), and an ID token (always a JWT) containing the user's identity. The ID token is for the client application "” it proves who the user is. The access token is for resource servers "” it proves what the bearer is authorized to do.

A common mistake is using the ID token as a bearer token for API calls. The audclaim of an ID token is the client ID, not the API "” resource servers should reject it. Always use the access token for API authorization.

Our decoder is particularly useful during OIDC integration: paste the ID token to check thatiss matches the provider URL, aud matches your client ID,nonce matches what you sent in the authorization request, and expshows the token has not expired.

JWT in Microservices: Service-to-Service Authentication

Modern microservice architectures need a way for services to authenticate to each other without user involvement. Machine-to-machine (M2M) JWTs solve this problem. A central identity server issues short-lived JWTs to services using the OAuth 2.0 Client Credentials flow. These tokens carry claims identifying the originating service and the services it is authorized to call.

In a typical microservice scenario: Service A needs to call Service B. Service A fetches an access token from the identity server using its client ID and secret. It attaches the token to the request to Service B. Service B verifies the token signature using the identity server's public key (from JWKS), validates the audience claim matches its own identifier, and processes the request.

Decoding the M2M token with our tool helps diagnose: wrong issuer, audience mismatch, token already expired (M2M tokens should be cached and reused until near expiry, not fetched on every request), or missing scope claims.

Common JWT Debugging Scenarios

401 Unauthorized: The Most Common JWT Problem

When your API returns 401 with a valid-looking JWT, work through this diagnostic checklist using our decoder:

First, check exp. Is the token expired? This is the most frequent cause "” tokens issued during development expire, or client code fails to refresh tokens properly.

Second, check aud. Does the audience match what your API expects? A token issued for https://api.example.com presented to https://admin.example.comwill be rejected by a properly configured API.

Third, check iss. Does the issuer match your API's configured issuer? A staging token presented to production will fail.

Fourth, check alg. Does the algorithm match what your server expects? A server configured to only accept RS256 will reject HS256 tokens and vice versa.

Fifth, check clock skew. If your server time is slightly ahead of the token's expbut the token looks like it has seconds left, time synchronization between services may be the issue. Most JWT libraries accept a small clock skew tolerance (30-60 seconds).

Missing Claims After Login

If your application expects a role, email, or permissionsclaim that is not present, the problem is almost always the OAuth 2.0 scopes requested. Most providers only include claims corresponding to requested scopes:

• openid scope → sub claim
• profile scope → name, given_name, picture
• email scope → email, email_verified

Custom claims like roles or permissions usually require explicit configuration on the authorization server "” often called "rules", "actions", or "claim mappers" depending on the provider.

Token Works in Development But Fails in Production

Decode both tokens (development and production) side by side. The most likely differences are: different issuers (staging vs production auth server URL), different audiences, different signing keys (wrong key configured in production), or different token lifetimes.

JWT Security: Attack Vectors and Mitigations

Algorithm Confusion Attacks

In an algorithm confusion attack, an attacker takes a JWT signed with RS256, changes thealg header to HS256, and signs the token using the RS256 public key as the HMAC secret. Libraries that do not explicitly validate the expected algorithm may attempt HS256 verification using the public key "” and succeed, because the attacker signed with exactly that value.

Mitigation: always explicitly specify the expected algorithm in your JWT library configuration. Never determine the algorithm from the token header "” the header is attacker-controlled.

JWT Injection

If your application constructs JWT payloads from user-supplied input without proper sanitization, an attacker may inject additional claims or override existing ones (in non-standard library implementations). Always construct the payload from server-side authoritative sources, not from user input.

Replay Attacks

A stolen JWT can be presented by an attacker as if they were the legitimate user until the token expires. Mitigations: use short expiration times, implement token binding (binding tokens to client certificates), use refresh token rotation with revocation, and include the jticlaim for single-use tokens.

Sensitive Data in Payload

JWT payloads are Base64URL encoded, not encrypted. Anyone who intercepts or receives the token can read all claims. Never include passwords, social security numbers, credit card numbers, medical records, or other sensitive personal data in JWT claims. Include only the minimum necessary claims for authorization decisions.

JWT Best Practices: A Complete Reference

Algorithm Selection

For most applications: use RS256 (or ES256 for smaller key sizes). RS256 allows the token issuer to keep the private signing key secret while distributing the public verification key to all resource servers "” resource servers can verify tokens but cannot mint new ones, providing defense in depth. HS256 is appropriate only when all verifying parties are fully trusted and can securely share the signing secret.

Token Lifetime

Access tokens: 15 minutes to 1 hour is a reasonable range for most applications. Highly sensitive applications (banking, healthcare) should use 5-15 minutes. Refresh tokens: 24 hours to 30 days depending on your session requirements, with rotation and revocation support.

Never issue access tokens with multi-day lifetimes. A stolen 90-day access token gives an attacker three months of unrestricted access. A stolen 15-minute token has a narrow window.

Storage in Browsers

Store tokens in memory (JavaScript variables) for the most security "” they disappear when the tab is closed. For persistent sessions, use HttpOnly, Secure, SameSite=Strict cookies, which cannot be accessed by JavaScript and are therefore immune to XSS attacks. Avoid localStorage and sessionStorage "” they are accessible to any JavaScript running on the page, including injected malicious scripts.

Claim Validation

Always validate: iss (must match expected issuer), aud (must include your service), exp (must be in the future), nbf (must be in the past if present), and the signature (must verify with the expected key using the explicitly configured algorithm). Validate all of these on every request "” do not cache validation results beyond the token lifetime.

Minimal Payload

Keep JWT payloads small. Every claim adds bytes to every request. Include only what is needed for authorization decisions. Fetch detailed user profiles from a database using the subclaim rather than embedding all profile data in the token. This keeps tokens small, reduces the attack surface from exposed claims, and avoids stale data problems when user attributes change.

Base64URL Encoding: Technical Details

Standard Base64 encodes 3 bytes of binary data as 4 ASCII characters using the alphabetA-Z a-z 0-9 + / with = padding. This is not URL-safe because+ and / are meaningful in URLs and HTTP headers.

Base64URL substitutes + → - and / → _, and omits the = padding characters. The result can appear in URL path segments, query parameters, and HTTP headers without any percent-encoding.

Our decoder handles Base64URL automatically. You can paste JWT strings directly "” with or without the Bearer prefix "” and the tool strips it and decodes correctly.

JWT Libraries by Language and Platform

Choosing the right JWT library is important "” not all libraries validate all security properties by default. Use maintained, widely-audited libraries and configure them explicitly:

Node.js / JavaScript

• jsonwebtoken (Auth0) "” the most popular; good defaults but configure algorithms explicitly
• jose "” modern, comprehensive JWK/JWKS support, OIDC-ready
• @auth0/jwt-decode "” client-side decode only, no verification

Python

• PyJWT "” clean API, good defaults; configure algorithms parameter
• python-jose "” JWK/JWKS support
• authlib "” full OAuth 2.0 + OIDC implementation including JWT

Java

• java-jwt (Auth0) "” popular, expressive API
• jjwt (Stormpath/JJWT) "” type-safe builder pattern
• nimbus-jose-jwt "” most complete JWA/JWE support
• Spring Security OAuth2 "” integrated with Spring ecosystem

Go

• golang-jwt/jwt "” idiomatic Go, actively maintained fork of dgrijalva/jwt-go
• lestrrat-go/jwx "” comprehensive JWK, JWE, JWS, JWT support

.NET

• System.IdentityModel.Tokens.Jwt "” Microsoft's official library
• Microsoft.AspNetCore.Authentication.JwtBearer "” ASP.NET Core middleware

Ruby

• ruby-jwt "” simple, widely used
• omniauth-jwt "” OmniAuth strategy using JWT

PHP

• firebase/php-jwt "” maintained by Firebase
• lcobucci/jwt "” type-safe, modern PHP 8 API

Rust

• jsonwebtoken "” safe, well-maintained Rust implementation

Comparing Our JWT Decoder to Alternatives

jwt.io

The jwt.io debugger created by Auth0 is the most well-known JWT tool. It is feature-rich and supports signature verification. However, it sends token data to Auth0's servers in some configuration modes and embeds Auth0 branding throughout. Our tool performs all decoding and verification client-side with zero server involvement and no third-party embedding.

Local Development Tools

Some developers use command-line tools like jwt-cli or base64 decoding in a terminal. Our online tool is faster to reach, provides syntax highlighting and expiration detection, and requires no installation "” ideal for quick inspection during debugging sessions.

Privacy and Security of Our Tool

All JWT decoding and verification runs entirely in your browser. The JavaScript that processes your token is delivered to your browser and runs locally "” no token data, no payload contents, no signature values are transmitted to our servers or any third party. The page makes no API calls during the decode operation.

We do not log tokens, store them in any database, include third-party analytics that might capture input field contents, or use service workers that could intercept network traffic. You can safely decode tokens containing sensitive claims including user IDs, email addresses, permissions, and tenant identifiers.

That said, adopt good hygiene: avoid sharing production administrator tokens with any tool out of habit. For tokens with the highest privilege levels, decode in a local tool or IDE. But for the daily work of debugging authentication flows, our browser-based decoder is the fastest and most convenient option available.