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.
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.
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.