Dev Tools

JWT Decoder

Decode JSON Web Tokens instantly. View header, payload, and expiration times. Runs entirely in your browser — your tokens never leave your device.

Privacy Notice

This tool runs 100% client-side. Your JWT is never sent to any server. All decoding happens in your browser.

About This Tool

The JWT Decoder is a privacy-focused developer tool for inspecting JSON Web Tokens. Paste any JWT token and instantly see its decoded header, payload claims, and time-related fields converted to human-readable dates. The tool runs entirely in your browser using JavaScript — your tokens are never transmitted to any server, making it safe to use with production tokens during debugging.

How JWTs Work

A JSON Web Token consists of three base64url-encoded parts separated by dots: the header, the payload, and the signature. The header typically contains two fields: "alg" (the signing algorithm, such as HS256 or RS256) and "typ" (the token type, always "JWT"). The payload contains claims — key-value pairs that carry the token's actual data. Claims can be registered (standard names like "sub" for subject, "exp" for expiration), public (custom names registered in the IANA JSON Web Token Claims registry), or private (application-specific names agreed upon by the parties). The signature is computed over the header and payload using the specified algorithm and a secret or private key, ensuring the token has not been tampered with.

Understanding Token Expiration

Most JWTs include an "exp" (expiration) claim that specifies when the token becomes invalid. This claim is a Unix timestamp — the number of seconds since January 1, 1970 UTC. Our decoder automatically detects time-related claims (exp, iat, nbf, auth_time) and displays them as human-readable local and UTC dates. The tool also shows a status badge indicating whether the token is currently valid, expiring soon (within 5 minutes), or already expired. This is invaluable when debugging authentication issues, as expired tokens are one of the most common causes of API 401 errors. The relative time display lets you quickly see how long until a token expires or how long ago it was issued.

JWT Security Considerations

It is a common misconception that JWTs are encrypted. They are not — the header and payload are merely base64url-encoded, which is a reversible encoding, not encryption. Anyone who obtains a JWT can read its contents. The signature provides integrity verification (proving the token has not been modified) and authentication (proving it was issued by a trusted party), but it does not provide confidentiality. This means you should never store sensitive information like passwords, credit card numbers, or personal identification numbers in JWT claims. If you need encrypted tokens, the JWE (JSON Web Encryption) standard extends JWT with payload encryption. For most web applications, standard signed JWTs are sufficient as long as they are transmitted over HTTPS and stored securely.

Common JWT Claims Explained

The JWT specification defines several standard claims. "iss" (issuer) identifies who created the token, typically your authentication server's URL. "sub" (subject) identifies the entity the token represents, usually a user ID. "aud" (audience) specifies the intended recipient, such as an API endpoint. "exp" (expiration time) sets the token's deadline. "nbf" (not before) prevents the token from being used before a certain time. "iat" (issued at) records when the token was created. "jti" (JWT ID) provides a unique identifier for the token, useful for preventing replay attacks. Beyond these standard claims, applications commonly add custom claims for roles, permissions, user email, organization ID, and other authorization-related data that the receiving service needs to make access control decisions.

Debugging with the JWT Decoder

When authentication fails in a web application, inspecting the JWT is often the first debugging step. Common issues revealed by decoding include: the token has expired (exp is in the past), the audience claim does not match the expected API (wrong aud), the issuer is unexpected (wrong iss, possibly a staging vs. production mismatch), required claims are missing (no role or permission), or the algorithm in the header does not match what the server expects. This decoder presents all this information in an organized, easy-to-scan format with color-coded status indicators, making it faster than manually base64-decoding in a terminal or writing throwaway code. The copy buttons for header and payload let you quickly share decoded token contents with teammates when collaborating on authentication issues.

Frequently Asked Questions

What is a JSON Web Token (JWT)?
A JSON Web Token (JWT, pronounced 'jot') is an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe JSON object. A JWT consists of three parts separated by dots: a header, a payload, and a signature. The header specifies the token type and signing algorithm. The payload contains claims — statements about the user or entity and additional metadata. The signature is used to verify that the token has not been tampered with. JWTs are widely used for authentication and authorization in web applications, APIs, and microservices architectures. After a user logs in, the server issues a JWT that the client includes in subsequent requests to prove their identity.
Is it safe to decode JWTs in the browser?
Yes, decoding a JWT in the browser is completely safe. The header and payload of a JWT are simply base64url-encoded JSON — they are not encrypted. Anyone who has the token can decode and read these sections. This is by design: JWTs are meant to be transparent and verifiable, not secret. The security of a JWT comes from its signature, which proves the token was issued by a trusted authority and has not been modified. This decoder only reads the header and payload; it does not verify signatures, which would require the secret key or public key. Never put sensitive information like passwords in JWT payloads, since they can be read by anyone who intercepts the token.
What do the exp, iat, and nbf claims mean?
These are registered claims defined in the JWT specification. 'exp' (expiration time) is the Unix timestamp after which the token should no longer be accepted. 'iat' (issued at) is the Unix timestamp when the token was created. 'nbf' (not before) is the Unix timestamp before which the token should not be accepted. All three use Unix epoch timestamps (seconds since January 1, 1970 UTC). This decoder automatically converts these timestamps to human-readable dates so you can quickly see when a token was issued and when it expires. The 'exp' claim is particularly important for security, as tokens should have a limited lifetime to reduce the window of vulnerability if a token is compromised.
Why does this tool not verify JWT signatures?
Signature verification requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA or ECDSA algorithms like RS256 or ES256). Since this is a client-side tool running in your browser, we do not ask for or handle signing keys. Verifying signatures is a server-side responsibility that happens in your application's authentication middleware. This tool focuses on inspecting and debugging token contents — viewing the algorithm, claims, expiration times, and payload data. For production signature verification, use server-side libraries like jsonwebtoken (Node.js), PyJWT (Python), or java-jwt (Java). Never share your signing secrets with client-side tools.
How long should a JWT expiration time be?
JWT expiration times depend on your security requirements and use case. Access tokens (used for API authentication) typically have short lifetimes of 5 to 60 minutes. This limits the damage if a token is stolen, since it will expire quickly. Refresh tokens, which are used to obtain new access tokens, can have longer lifetimes of days to weeks, but should be stored securely (HTTP-only cookies) and be revocable. For highly sensitive operations (banking, healthcare), very short expiration times of 5-15 minutes are recommended. For less sensitive applications, 1-24 hours may be acceptable. The tradeoff is between security (shorter) and user experience (longer, fewer re-authentication prompts). Always implement token refresh mechanisms rather than using very long-lived access tokens.
What JWT signing algorithms are commonly used?
The most common JWT algorithms are HS256 (HMAC with SHA-256), RS256 (RSA with SHA-256), and ES256 (ECDSA with P-256 curve). HS256 uses a shared secret key for both signing and verification, making it simpler but requiring both parties to have the same secret. RS256 uses an asymmetric key pair — a private key for signing and a public key for verification — which is more secure for distributed systems where multiple services need to verify tokens. ES256 also uses asymmetric keys but with elliptic curve cryptography, producing smaller signatures. The algorithm is specified in the JWT header's 'alg' field. The 'none' algorithm should never be used in production as it means no signature verification, creating a critical security vulnerability.

Was this tool helpful?

You might also like

Tax & Finance

Self-Employment Tax Estimator

Calculate your quarterly SE tax payments and deductions.

⏱ 2 minFinance

Compound Interest Calculator

See how your money grows with compound interest over time.

⏱ 1 minCareer

Freelance Rate Calculator

Find your ideal hourly, daily, and project rates.

⏱ 3 min