Related Tools
How to Use
- 1Paste your JWT token (the full string including the two dots) into the input field.
- 2Review the decoded Header to identify the signing algorithm (e.g., HS256, RS256) and token type.
- 3Inspect the Payload section for standard claims: sub (subject/user ID), iss (issuer), aud (audience), iat (issued at), and exp (expiration timestamp).
- 4Read the expiration status indicator — it shows whether the token is currently valid and how much time remains before it expires (or how long ago it expired).
- 5Use the copy buttons to copy the header or payload JSON for use in debugging, logging, or documentation.
- 6Paste a different token at any time to decode it without refreshing the page.
About JWT Decoder
The JWT Decoder parses JSON Web Tokens and displays the header and payload as formatted, readable JSON. It extracts the signing algorithm (HS256, RS256, ES256, etc.) from the header and all claims from the payload — including standard registered claims like sub (subject), iss (issuer), aud (audience), iat (issued at), exp (expiration), and nbf (not before), as well as any custom claims your application includes.
The expiration status is calculated automatically by comparing the exp claim against the current time. You can see at a glance whether a token is still valid, how long until it expires, or how long ago it expired. This is the single most useful feature when debugging authentication failures — the majority of 401 Unauthorized errors in development and staging environments are caused by expired tokens, and being able to check expiration instantly saves significant debugging time.
JSON Web Tokens (JWTs, pronounced 'jots') are the dominant standard for stateless authentication and authorization in modern web applications, defined by RFC 7519. A JWT consists of three Base64url-encoded segments separated by dots: the header (algorithm and token type), the payload (claims about the user and session), and the signature (cryptographic proof that the header and payload have not been tampered with). This tool decodes the first two segments — the header and payload — which do not require any secret key to read.
JWTs appear throughout modern software architecture. They are the Bearer tokens in HTTP Authorization headers, the id_tokens and access_tokens in OAuth 2.0 and OpenID Connect flows, the session tokens in single sign-on (SSO) systems, and the authorization tokens in API gateways like Kong, AWS API Gateway, and Cloudflare Access. Understanding what is inside a JWT is essential for debugging login flows, verifying that user roles and permissions are correctly encoded, and ensuring that tokens carry the expected claims.
This tool only decodes the token — it does not verify the cryptographic signature. Signature verification requires the signing secret (for symmetric algorithms like HS256) or the public key (for asymmetric algorithms like RS256 and ES256). You should never paste signing secrets into any browser-based tool. For signature verification, use server-side libraries like jsonwebtoken (Node.js), PyJWT (Python), or java-jwt (Java).
All decoding happens entirely in your browser by splitting the token string on dots and Base64url-decoding the first two segments. Your token is never transmitted to any server, never logged, and never stored. This makes the tool safe for inspecting tokens from development, staging, and even production environments — though you should always be cautious about pasting production tokens on shared or public screens.
Frequently Asked Questions
Does this tool verify the JWT signature?
No. This tool only decodes the Base64url-encoded header and payload, which do not require any secret or key to read. Signature verification requires the signing secret (for HS256) or the public key (for RS256/ES256), which should never be entered into a browser tool. Use server-side libraries like jsonwebtoken (Node.js) or PyJWT (Python) for verification.
How do I check if my JWT is expired?
Paste the token and the tool reads the exp (expiration) claim automatically. It displays whether the token is currently valid, how much time remains before expiration, or how long ago it expired. This is the fastest way to diagnose 401 errors caused by token expiration during development.
What do the iat, exp, sub, and iss claims mean?
These are registered claims defined in the JWT specification (RFC 7519). iat = issued at (Unix timestamp when the token was created), exp = expiration (Unix timestamp after which the token is invalid), sub = subject (typically the user ID), iss = issuer (the service that created the token, like your auth server URL), aud = audience (the intended recipient, like your API). Custom claims (roles, permissions, email) vary by application.
Can I use this to debug tokens from Auth0, Firebase, or AWS Cognito?
Yes. Tokens from any standard JWT-issuing service — Auth0, Firebase Auth, AWS Cognito, Keycloak, Okta, Azure AD, Google Identity Platform — follow the same Base64url format and decode correctly. You will see both the standard claims and any platform-specific custom claims these services include in the payload.
What is the difference between HS256 and RS256?
HS256 (HMAC-SHA256) uses a single shared secret for both signing and verification — fast and simple, but the secret must be shared with every service that needs to verify tokens. RS256 (RSA-SHA256) uses an asymmetric key pair — the private key signs the token and the public key verifies it. RS256 is preferred for microservice architectures and multi-tenant systems because you can distribute the public key freely without exposing the signing key.
Is my JWT token safe to paste here?
Yes. Decoding happens entirely in your browser using JavaScript — the token is never transmitted to any server, never logged, and never stored. However, remember that JWT payloads are only encoded, not encrypted — anyone with the token string can decode the payload. Avoid pasting production tokens on shared screens or in environments where others can see your clipboard.
Why can anyone read the JWT payload without the secret key?
JWTs are designed for integrity, not confidentiality. The payload is Base64url-encoded (not encrypted) so that any party can read the claims. The signature ensures the payload has not been tampered with, but it does not hide the content. If you need to hide payload data, use JWE (JSON Web Encryption) instead of standard JWTs, or avoid putting sensitive data in the token payload.
What does a JWT look like?
A JWT is a string of three Base64url-encoded segments separated by dots: xxxxx.yyyyy.zzzzz. The first segment is the header (algorithm and type), the second is the payload (claims), and the third is the signature. The header and payload are JSON objects encoded in Base64url. The signature is a cryptographic hash of the header and payload, signed with the secret or private key.