JWT Decoder
Decode JWT tokens and inspect header, payload, and signature. Runs locally — your tokens stay private.
How to use JWT Decoder
- 1Paste your JWT
Paste the full JWT (three base64url parts separated by dots).
- 2View decoded payload
Header and payload are decoded and pretty-printed. Signature is shown raw.
About JWT Decoder
JSON Web Tokens (JWT, pronounced "jot") are compact, URL-safe tokens used for authentication and authorization in modern APIs. A JWT consists of three Base64URL-encoded parts separated by dots: a header (signing algorithm and token type), a payload (claims like user ID, expiration, custom data), and a signature (verifies the token was not tampered with).
A crucial point: the header and payload are NOT encrypted. Anyone can decode them — that is exactly what this tool does. The signature only proves the token was issued by someone who knows the secret or private key; it does not hide the contents. Treat every JWT as a sensitive credential regardless of whether it has been validated, because anyone holding it can use it. Utilify's decoder splits the token, Base64URL-decodes the header and payload, and pretty-prints the JSON. Signature verification requires the secret or public key and is intentionally out of scope.
The payload carries claims. Registered claims have standard meanings: "sub" (subject, usually the user ID), "iss" (issuer), "aud" (audience), "exp" (expiration time), "iat" (issued-at time), and "nbf" (not-before). All three time claims are Unix timestamps in seconds, which is why an expired-token bug is often just a clock or timezone misunderstanding — decode the token and convert "exp" to a readable date to confirm. Everything else in the payload is a custom claim your application defined.
Decoding is a debugging aid, not a security check. In production you must always verify the signature server-side with the issuer's key and confirm "exp", "iss", and "aud" before trusting any claim — never make authorization decisions on a decoded-but-unverified token. Watch the header's "alg" field too: a token claiming "alg": "none", or one quietly switched from RS256 to HS256, is a classic sign of a forgery attempt against a poorly configured verifier.
This tool deliberately stops at decoding so you can inspect exactly what a token asserts without implying it is trustworthy. That makes it ideal for the everyday questions — what is in this token, when does it expire, who issued it — while leaving the cryptographic trust decision where it belongs: on your server.
Decoding vs verifying — what this tool can and cannot tell you
A JWT decoder and a JWT verifier answer different questions. Knowing the difference is the single most important thing about working with tokens:
| Decoding (this tool) | Verifying (your server) | |
|---|---|---|
| What happens | Base64URL-decodes the header and payload into readable JSON | Recomputes the signature with the secret or public key and compares |
| Needs the key? | No — the payload is plain encoding, not encryption | Yes — HMAC secret (HS256) or public key (RS256/ES256) |
| Proves authenticity? | No. Anyone can decode any JWT, including a forged one | Yes. A valid signature proves the token was not altered |
| When to use | Debugging claims, checking exp, inspecting what a token carries | Every single time you trust a token in production |
When to use JWT Decoder
- Debugging auth issues
Inspect token claims (sub, exp, iss, aud) when sessions misbehave.
- Validating issuer claims
Confirm the iss and aud fields match what your service expects before deploy.
- Checking expiration
See the exp timestamp in human-readable form to diagnose expired-token errors.
JWT mistakes that turn into security incidents
- Trusting a token because it decoded
Decoding requires no key, so a decoded payload proves nothing about who issued it. Every production code path must verify the signature before reading claims — a forged token decodes just as cleanly as a real one. This is exactly why we built this page as a decoder and not a verifier: inspecting claims is safe to do locally in your browser, while verification belongs on your server, with your key.
- Putting secrets in the payload
A JWS payload (the common JWT) is only Base64URL-encoded — everyone who holds the token can read it. Never store passwords, PII you would not show the user, or internal flags there. If the contents must be confidential, you need JWE (encrypted JWT), not JWS.
- Letting the token choose its own algorithm
Verifiers that honor the alg header from the token itself are open to alg:none and RS256-to-HS256 confusion attacks. Pin the accepted algorithms in server configuration and reject everything else.
{"alg": "none"} ← a verifier must never accept this from the token - Ignoring clock skew on exp and nbf
Servers with slightly drifting clocks will reject freshly issued tokens (nbf in the future) or accept just-expired ones inconsistently. Standard practice is 30–60 seconds of leeway when validating time claims.
- Confusing expiry with revocation
JWTs are stateless: nothing happens at logout unless you build it. If you need to ban a user or kill a session before exp, you need a denylist or short-lived access tokens plus refresh tokens.
Frequently asked questions
Does this verify the JWT signature?+
No — this is a decoder only. Verifying a signature requires the issuer's public key or shared secret and should always be done server-side.
Is my JWT sent anywhere?+
No. Decoding happens entirely in your browser. Treat any JWT as a secret regardless, since anyone holding it can use it.
What do sub, exp, iss, and aud mean?+
"sub" is the subject (usually the user ID), "iss" is the issuer, "aud" is the intended audience, and "exp" is the expiration time as a Unix timestamp. "iat" (issued-at) and "nbf" (not-before) are also common.
Is the JWT payload encrypted?+
No. The header and payload are only Base64URL-encoded, so anyone can read them. The signature proves the token was not altered — it does not hide the contents.
Why does my token say it is expired?+
Decode it and convert the "exp" claim — a Unix timestamp in seconds — to a readable date. Expired-token bugs are often a clock skew or timezone mix-up rather than a real expiry.
Related tools
Format, beautify, and validate JSON online. Free, fast, runs entirely in your browser.
Validate JSON syntax online with clear error messages and line numbers. Free and private.
Encode and decode Base64 strings online. UTF-8 safe, browser-only — your data never leaves your device.
From the blog
A JWS (signed JWT) has 3 parts; a JWE (encrypted JWT) has 5. Learn what each JOSE acronym means, when a token is signed vs encrypted, and which you need.
RFC 7519 defines 7 registered JWT claims: iss, sub, aud, exp, nbf, iat, jti. Learn what each means, how to validate it, and the checks that stop attacks.