JWT Decoder
Decode any JSON Web Token to inspect its header, payload, and claims in a readable form — and optionally verify an HMAC (HS256/384/512) signature. Everything stays in your browser.
How to use JWT Decoder
- 1
Paste your token
Paste an encoded JSON Web Token into the input field. The decoder splits it into header, payload, and signature automatically.
- 2
Read the claims
Inspect the decoded header and payload as formatted JSON, and review registered claims like expiry and issued-at shown as readable dates.
- 3
Verify the signature
For HMAC tokens, enter the signing secret to confirm the signature is valid and the token has not been tampered with.
- 4
Copy what you need
Copy the formatted header or payload JSON to your clipboard to use in tests, documentation, or debugging.
Understanding JSON Web Tokens: Anatomy, Claims, and Pitfalls
Three parts separated by dots
A JSON Web Token is one long string with two dots in it, splitting it into three segments: header, payload, and signature. Each of the first two segments is a small JSON object that has been Base64URL-encoded — a URL-safe variant of Base64 that swaps a couple of characters and drops padding so the token travels cleanly in headers and query strings. The third segment is the signature, computed over the first two.
Paste a token and the decoder splits it on the dots and Base64URL-decodes the first two parts back into readable JSON. You see the header and payload exactly as the issuer wrote them. The reason this is possible at all is the crux of everything that follows: those segments are merely encoded, not encrypted.
The header: algorithm and type
The header is the smallest part. It typically declares the type — JWT — and, more importantly, the signing algorithm in its alg field. Common values are HS256, which uses an HMAC with a shared secret, and RS256 or ES256, which use asymmetric key pairs where a private key signs and a public key verifies. The algorithm tells a verifier how the signature was produced and therefore how to check it.
The alg field is also security-relevant. A token claiming an algorithm of none, or an attacker swapping a token from an asymmetric algorithm to a symmetric one to trick a naive verifier into using the public key as an HMAC secret, are classic attacks. A correct verifier pins the expected algorithm rather than blindly trusting whatever the header says.
The payload and its registered claims
The payload carries the claims — the statements the token makes. A set of registered claim names is standardized so that different systems agree on their meaning. The issuer claim (iss) names who created the token, the subject claim (sub) identifies who or what it is about (often a user ID), and the audience claim (aud) names the intended recipient. Alongside these you will usually find custom application claims like a role or a tenant.
This decoder surfaces the registered claims in a labeled, human-readable form so you do not have to recognize the cryptic short names by heart. Seeing the issuer, subject, and audience spelled out is often all you need when you are eyeballing a token during debugging to confirm it is the right one for the right service.
Time claims: exp, iat, and nbf
Three claims govern a token's lifetime, and all of them are Unix timestamps measured in seconds — not milliseconds, which is a frequent off-by-a-thousand bug for JavaScript developers used to millisecond time. The expiration claim (exp) is the instant after which the token must be rejected, the issued-at claim (iat) records when it was created, and the not-before claim (nbf) marks the earliest moment it becomes valid.
The decoder converts these to readable dates and tells you whether the token is currently active, not yet valid, or expired according to your device's clock. That last detail matters: if your computer's clock is wrong, the active-or-expired verdict can be misleading, and in production a clock skew between servers is a common reason a freshly issued token is rejected as not-yet-valid.
Decoding is not verifying
This is the single most important thing to internalize. Anyone can decode a JWT — it is just Base64URL — so reading the claims tells you what the token says, not whether the token is genuine. Trust comes only from checking the signature against the key, which proves the token was issued by a party holding the secret or private key and has not been altered since.
For HMAC tokens (HS256, HS384, HS512) this tool can recompute the signature from the header, payload, and the secret you provide and compare it to the token's signature, confirming authenticity for that secret. Asymmetric algorithms such as RS256 and ES256 require the issuer's public key and are decoded but not verified here. Critically, real authorization decisions must verify the signature server-side; never trust a token's claims based on decoding alone in client code.
The payload is not secret
Because the payload is only encoded, every claim inside it is plainly visible to anyone who gets the token — the browser, any proxy, the user themselves. A JWT is a great place for non-sensitive identity and authorization data, and a terrible place for anything confidential. Never put a password, an API secret, a credit card number, or private personal data in the payload thinking the encoding protects it. It does not.
The signature protects integrity, not confidentiality: it stops tampering, but it does nothing to hide the contents. If you genuinely need an encrypted token whose payload cannot be read, that is a different, heavier construct (JWE) — a standard JWT is signed, not encrypted. Keep secrets on the server and reference them by an opaque identifier in the token instead.
Debugging tokens safely
In day-to-day work the decoder shines for debugging auth flows: confirm the right user is in the subject claim, check that the audience matches the service rejecting the request, verify the scopes or roles are present, and read the expiry to see whether a 401 is simply a stale token. Copying the formatted header or payload into a bug report or test fixture is a one-click step.
Everything happens locally in your browser — the token and any secret you type are never uploaded, logged, or stored — so it is safe to inspect real production tokens. That said, treat tokens like the credentials they are: a valid, unexpired token is a live key to an account, so avoid pasting one into untrusted tools, and prefer expired or test tokens when sharing examples.
Frequently asked questions
What is a JSON Web Token (JWT)?
Does decoding a JWT reveal the password or secret?
How does signature verification work here?
What do the exp and iat claims mean?
Is my token sent to a server?
Related tools
Keep going with these handy tools