RevealTheme logo

JWT Decoder

Decode JSON Web Tokens (JWTs) instantly. Runs in your browser — tokens never leave your device, safe to use with production secrets.

How to use this tool

  1. 1

    Paste your JWT into the input field.

  2. 2

    Click Decode. The header and payload are parsed and displayed.

  3. 3

    Inspect the algorithm, claims, expiry, and issuer.

What is a JWT and how does it work?

A JSON Web Token (JWT, defined in RFC 7519) is a compact, URL-safe way to represent a set of claims about a user, with cryptographic proof those claims weren't tampered with. JWTs power authentication in most modern web stacks: when you log in, the server creates a JWT containing your user ID and permissions, signs it with a secret key, and sends it back. Your browser stores the token (usually in localStorage or a cookie) and includes it in the Authorization header of every subsequent request. The server verifies the signature on each request — if it's valid, the claims inside the token are trusted; if it's tampered, the signature breaks and the request is rejected. JWTs have three Base64URL-encoded parts separated by dots: the header declares the signing algorithm (HS256 for HMAC-SHA256, RS256 for RSA, ES256 for ECDSA, none for unsigned tokens — which is dangerous and you should reject those); the payload contains the actual claims (standard claims like 'sub' for subject, 'exp' for expiration, 'iat' for issued-at, plus any custom claims your application defines); the signature is proof the header and payload were signed by someone who held the secret. This decoder reveals the first two parts, which are public information — the signature can only be verified with the key, which is why every JWT decoder displays the claims without verification.

Common use cases

  • Debug authentication problems by decoding the JWT your client is sending — see exactly which claims are present, who issued it, and when it expires.

  • Inspect API gateway JWTs (AWS Cognito, Auth0, Okta) to understand the claims structure for downstream services.

  • Verify that custom claims (organization ID, role, feature flags) are being set correctly in the token-issuance code.

  • Compare tokens before and after a refresh to confirm the expiry was extended.

  • Audit a token's algorithm — confirm RS256 or ES256 is used in production, never 'none'.

  • Translate base64url payloads from server logs into human-readable claims.

Frequently asked questions

Is this safe to use with production JWTs?
Yes. Decoding happens entirely in your browser using local JavaScript — the token never reaches our servers, never appears in any log. You can verify by opening DevTools → Network tab while you decode: no outbound request fires. That said, treat JWTs as credentials — don't paste them into URLs, screenshots, or shared documents, regardless of where the decoder runs.
Does this verify the signature?
No. Signature verification requires the secret (for HS256) or public key (for RS256/ES256/PS256). Web tools that ask for your secret to verify a JWT are a security smell — you'd be sending your signing key to a stranger. Verify signatures server-side or with a library you control (jose, jsonwebtoken).
What if my JWT is expired?
Expiry doesn't prevent decoding — the 'exp' claim is just data in the payload. Look for 'exp' in the decoded payload: it's a Unix timestamp (seconds since 1970). Convert it with our Timestamp Converter to see the expiry in your timezone. If exp is past, the token is rejected by any compliant verifier even though the decoder still reads it.
Can JWTs be encrypted?
Yes — that's called JWE (JSON Web Encryption, RFC 7516). This tool handles JWS (JSON Web Signature, the common case), where the payload is signed but visible. JWE tokens have 5 dot-separated parts instead of 3 and require the recipient's private key to decrypt. If your token has 5 parts, you need a JWE-aware tool.
What does 'alg': 'none' mean and is it dangerous?
'none' means no signature — the token is unsigned, anyone can forge any claims. Production systems should explicitly reject 'alg: none' tokens. Some libraries default to accepting them (a well-known CVE class). Always allowlist the algorithms your application expects.
Why use JWTs instead of session cookies?
JWTs are stateless — the server doesn't need to look up a session; the token itself contains the user's identity and permissions. This makes JWTs ideal for distributed systems and APIs. Session cookies are stateful (server-side session storage required) but easier to invalidate (just delete the session). The trade-off: JWTs scale better, but you can't 'log a user out' until the token expires.
What are the standard JWT claims?
RFC 7519 defines: iss (issuer), sub (subject — usually user ID), aud (audience), exp (expiration time), nbf (not before), iat (issued at), jti (JWT ID). Beyond those, applications add custom claims like 'roles', 'permissions', 'tenant_id'. Keep custom claims small — JWTs travel in every request header and grow your bandwidth.

Related tools