Free JWT Decoder
Paste a JSON Web Token and instantly decode it to inspect the header, payload, and signature as defined by RFC 7519. See the algorithm (HS256, RS256, ES256), registered claims (sub, iat, exp, iss, aud, nbf, jti), expiration status, and issued date — all processed locally in your browser. JWTs are the backbone of modern authentication in OAuth 2.0, OpenID Connect, and API authorization flows, and this tool lets you debug them without exposing sensitive token data to third-party services. No server, no signup, no data sent anywhere — your tokens stay on your device.
Loading...
Need expert help with AI?
Looking for a specialist to help integrate, optimize, or consult on AI systems? Book a one-on-one technical consultation with an experienced AI consultant to get tailored advice.
What Is a JWT Token and Why Decode It?
JSON Web Tokens (JWTs) are the standard way modern web applications handle authentication and authorization. Defined by RFC 7519, a JWT is a compact, URL-safe string consisting of three Base64url-encoded parts separated by dots: a header that specifies the signing algorithm (such as HS256, RS256, or ES256), a payload containing claims about the user or session, and a cryptographic signature that ensures the token has not been tampered with. When you log in to an application, the server creates a signed JWT containing your user ID, permissions, and expiration time, and this token is sent with every subsequent API request.
Decoding a JWT lets you see exactly what claims it contains — which user it belongs to (the "sub" claim), when it was issued ("iat"), when it expires ("exp"), who issued it ("iss"), and who it is intended for ("aud"). This is essential for debugging authentication issues during development, verifying that token payloads contain the correct permissions and scopes, and understanding the OAuth 2.0 and OpenID Connect flows used by identity providers like Auth0, Firebase, AWS Cognito, and Okta.
JWT Security Considerations and Best Practices
While JWTs are widely used and well-specified, they require careful handling. The token payload is only Base64url-encoded, not encrypted — anyone who intercepts a JWT can decode it and read the claims. This is why JWTs should always be transmitted over HTTPS and stored securely (in httpOnly cookies or short-lived memory, not localStorage). Short expiration times (5-15 minutes) combined with refresh tokens limit exposure if a token is compromised. The signing algorithm should be explicitly validated on the server side to prevent "none" algorithm attacks where an attacker strips the signature entirely.
Choosing the right signing algorithm matters. HS256 (HMAC-SHA256) uses a shared secret, which is simple but means every service that needs to verify tokens must have the secret. RS256 (RSA-SHA256) and ES256 (ECDSA P-256) use asymmetric key pairs — the auth server signs with a private key, and any service can verify with the published public key. This is the preferred approach for microservices and distributed systems. Identity providers publish their public keys at a JWKS (JSON Web Key Set) endpoint, allowing services to verify tokens without sharing secrets.
Common JWT Usage Patterns in Modern Applications
JWTs are the token format specified by the OAuth 2.0 and OpenID Connect standards, making them the backbone of modern authentication. In a typical OAuth 2.0 flow, a user authenticates with an identity provider (like Google, Auth0, or AWS Cognito), which issues an access token (authorizing API requests) and an ID token (containing user profile information) — both as JWTs. Single-page applications and mobile apps store these tokens and attach them to API requests via the Authorization header, enabling stateless authentication across distributed backend services.
Beyond authentication, JWTs are used in API gateways (AWS API Gateway, Kong, Cloudflare Access) to enforce authorization policies at the edge before requests reach backend services. They are used in service-to-service communication within microservice architectures to propagate user context without centralized session storage. They also appear in webhook signatures, email verification links, and password reset tokens where a self-contained, tamper-proof payload is needed. Understanding the structure and claims of these tokens is essential for any developer working with modern web APIs.
More Free Tools
How It Works
Paste your JWT token into the input field.
Click Decode to view the header, payload, and signature.
Check expiration status and copy individual sections.
Key Features
Privacy & Trust
Use Cases
Frequently Asked Questions
What is a JSON Web Token (JWT)?
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe token format defined by RFC 7519. It consists of three Base64url-encoded parts separated by dots: a header specifying the signing algorithm and token type, a payload containing claims about the user or session, and a cryptographic signature that proves the token has not been tampered with. JWTs are the standard token format for OAuth 2.0 access tokens, OpenID Connect ID tokens, and stateless API authentication. They allow servers to verify a user's identity and permissions without querying a database on every request.
What are the common JWT claims and what do they mean?
RFC 7519 defines seven registered claims: "sub" (subject — the user or entity the token represents), "iss" (issuer — who created the token, e.g., your auth server URL), "aud" (audience — the intended recipient, e.g., your API), "exp" (expiration time — when the token becomes invalid), "nbf" (not before — the earliest time the token is valid), "iat" (issued at — when the token was created), and "jti" (JWT ID — a unique identifier to prevent replay attacks). Beyond these, tokens often include custom claims like "email," "name," "roles," or "scope" that carry application-specific data. This decoder displays all of them.
What signing algorithms do JWTs use?
JWTs support several signing algorithms defined by the JSON Web Algorithms (JWA) specification. HS256 (HMAC-SHA256) is a symmetric algorithm where the same secret key signs and verifies the token — simple but requires sharing the secret. RS256 (RSA-SHA256) is asymmetric, using a private key to sign and a public key to verify — ideal for distributed systems where multiple services need to validate tokens. ES256 (ECDSA P-256) offers similar asymmetric security with smaller keys and faster verification. PS256 uses RSA-PSS padding for improved security. EdDSA (Ed25519) is the newest option, offering excellent performance and compact signatures. This decoder reads the "alg" field from the header and displays it alongside the decoded payload.
Is it safe to decode production tokens in this tool?
Yes. All decoding happens entirely in your browser using JavaScript — no token data is transmitted to any server, logged, or stored. You can verify this by opening the Network tab in your browser DevTools while decoding a token. That said, a decoded JWT payload may contain personally identifiable information like email addresses, user IDs, or role assignments, so you should still avoid pasting decoded contents into public forums, screenshots, or chat messages. The token itself is only as safe as your browser session.
How is JWT authentication different from session cookies?
With session-based authentication, the server stores session data in a database or memory store (like Redis) and sends the client a session ID cookie. Every request requires the server to look up the session. With JWT authentication, all the session data is encoded inside the token itself, so the server only needs to verify the signature — no database lookup required. This makes JWTs ideal for stateless, horizontally-scaled APIs and microservice architectures where sharing a session store across servers is impractical. The tradeoff is that JWTs cannot be individually revoked without maintaining a blocklist, whereas session cookies can be invalidated instantly by deleting the server-side session.
How are JWTs different from API keys?
API keys are static, opaque strings that act as simple credentials — the server must look up each key in a database to determine what access it grants. JWTs are self-contained tokens that carry their own claims (user identity, permissions, expiration) and are cryptographically signed, so the server can verify them without a database call. API keys typically do not expire unless manually rotated, creating a security risk if leaked. JWTs have built-in expiration (the "exp" claim), limiting the window of exposure. In practice, many systems use both: an API key to identify the application, and a JWT to authenticate the individual user within that application.
Can this tool verify JWT signatures?
No. Signature verification requires the secret key (for HS256) or the public key (for RS256, ES256, or EdDSA) that corresponds to the key used to sign the token. Since this tool runs entirely in your browser and does not connect to any key server, it cannot verify signatures. It decodes and displays the header, payload, and raw signature bytes. To verify a signature, you would need the signing key and a library like jsonwebtoken (Node.js), PyJWT (Python), or the jose library (JavaScript). Services like Auth0 and Firebase publish their public keys at well-known JWKS endpoints for this purpose.
What is the difference between JWS and JWE?
JWS (JSON Web Signature, RFC 7515) is a signed token — the payload is Base64url-encoded and readable by anyone, but the signature proves it has not been tampered with. This is what most people mean when they say "JWT," and it is what this tool decodes. JWE (JSON Web Encryption, RFC 7516) is an encrypted token — the payload is encrypted so that only the intended recipient with the decryption key can read it. JWE tokens have five dot-separated parts instead of three. If your token has five parts, it is a JWE and cannot be decoded by this tool without the decryption key. In practice, JWS is far more common; JWE is used when the token payload itself must be confidential in transit.
Can I decode tokens from Auth0, Firebase, AWS Cognito, and Okta?
Yes. This tool decodes any standard JWT regardless of the issuer. Auth0 issues JWTs signed with RS256 by default and includes claims like "azp" (authorized party) and custom namespaced claims. Firebase Authentication tokens use RS256 and include "firebase" as a custom claim with sign-in provider details. AWS Cognito issues both access tokens and ID tokens as JWTs with claims like "cognito:groups" and "token_use." Okta tokens include "scp" (scopes) and "cid" (client ID). Paste any of these into the decoder and you will see every claim the provider embedded in the token.
What does the exp claim mean and how is expiration checked?
The "exp" (expiration time) claim is a Unix timestamp (seconds since January 1, 1970 UTC) that specifies when the token becomes invalid. This decoder reads the "exp" value, converts it to a human-readable date, and compares it to your device's current time to show whether the token is still valid or has expired. Short-lived tokens (5-15 minutes) are a security best practice because they limit the damage if a token is leaked. Refresh tokens or silent re-authentication are used to obtain new access tokens without forcing the user to log in again. If your token has no "exp" claim, it never expires — which is generally considered a security risk.
Why are JWTs used instead of server-side sessions?
JWTs became popular with the rise of single-page applications (SPAs), mobile apps, and microservice architectures. In these environments, maintaining a centralized session store becomes a bottleneck and a single point of failure. JWTs are self-contained — any server with the signing key can verify them independently, enabling horizontal scaling without shared state. They also work well across domains (unlike cookies, which are bound to a single domain), making them ideal for APIs consumed by web apps, mobile apps, and third-party integrations simultaneously. The OAuth 2.0 and OpenID Connect specifications standardized JWTs as the token format, cementing their role in modern authentication.
Is there a maximum size for a JWT token?
There is no hard limit in the JWT specification itself, but practical limits exist. Most web servers and browsers impose header size limits — Nginx defaults to 8KB for all headers combined, Apache defaults to 8KB per header, and AWS API Gateway limits headers to 10KB. Since JWTs are typically sent in the Authorization header, a token exceeding a few kilobytes can cause "431 Request Header Fields Too Large" errors. In practice, a well-designed JWT should be under 2KB. If your tokens are growing large, consider moving bulky claims (like detailed permissions) to an API endpoint and keeping only essential claims (sub, exp, iss, roles) in the token.
Is this JWT Decoder free?
Yes, it is 100% free with no usage limits, no signup, and no per-decode charges. Many developer tools charge for premium features or limit free usage, but because this decoder runs entirely in your browser with no backend, there are no server costs to pass on. Use it as many times as you need for debugging, development, or learning.
Does this tool check if my JWT is expired?
Yes. When you decode a token, the tool reads the "exp" (expiration time) and "iat" (issued at) claims from the payload, converts the Unix timestamps to human-readable dates in your local timezone, and displays whether the token is currently valid or expired. This is one of the most common reasons developers decode JWTs — to quickly check whether an authentication failure is caused by an expired token before diving into server logs or code.
What happens if I paste an invalid or malformed token?
If the input is not a valid JWT (not three dot-separated Base64url-encoded segments), the tool will show an error indicating the token could not be decoded. Common causes of malformed tokens include accidentally copying extra whitespace, truncating the token when pasting from a terminal, or pasting a JWE (five-part encrypted token) instead of a JWS (three-part signed token). Make sure you copy the complete token string including all three parts separated by dots.
Limitations
- Cannot verify signatures — verification requires the secret key or public key used to sign the token
- Does not support JWE (JSON Web Encryption) — only decodes signed JWTs (JWS)
- Only decodes standard Base64url-encoded JWTs with three dot-separated parts
- Does not validate token claims against an authorization server
- Nested JWTs (a JWT inside a JWT payload) are displayed as raw strings
Q&A SESSION
Got a quick technical question?
Skip the back-and-forth. Get a direct answer from an experienced engineer.
