Security

JWT Decoder

Decode and inspect JSON Web Tokens.

Ctrl + Enter Copy decoded · Ctrl + Shift + C Copy all

JSON Web Tokens, explained

Anatomy of a JSON Web Token

A JWT is a compact, URL-safe string made of three base64url-encoded parts joined by dots: header.payload.signature. Each part plays a distinct role in carrying the token's claims and proving its authenticity.

The header declares how the token was signed — the algorithm (alg) and, when present, the key identifier (kid) a verifier needs to locate the right signing key. The payload carries the claims: statements about the subject, when the token was issued, and when it expires. The signature binds the two together so any tampering is detectable.

This decoder splits a token into those three parts and renders each independently, so you can inspect exactly what a server will see when it processes the token.

How JWT Signing Works

JWTs are signed with a key held by the issuer. The signature is the output of the chosen algorithm over the header and payload. An HMAC algorithm (HS256, HS384, HS512) uses a shared secret — both the issuer and every verifier must know it. Asymmetric algorithms (RS256, ES256, PS256) use a private key to sign and a public key to verify, so verifiers never need the secret.

This decoder does not verify signatures. A signature can only be checked against the issuer's key, which lives on the server. Decoding without verification is safe — the data is base64url, not encrypted — but until the signature is checked, the payload should be treated as untrusted.

When a signer chooses 'none', the JWT carries no integrity protection at all. Every value it contains should be treated as attacker-controlled, and production servers should reject such tokens outright.

Registered Claims You Should Know

The JWT spec registers a small set of claims with defined meanings. The most important are sub (the subject the token is about), iss (who issued it), and aud (the audience that should accept it). Expiration (exp), issued-at (iat), and not-before (nbf) are time claims expressed as Unix timestamps in seconds.

Issuers can also add application-specific claims — roles, permissions, a user's display name. OpenID Connect layers on its own claims like azp (the authorized party / client that received the token) and nonce (a replay guard).

This tool recognizes the registered claims and options, and labels every standard claim it finds with its meaning, so you never have to wonder what a claim like 'azp' stands for.

Understanding iat, exp, and nbf

Time claims are Unix timestamps: whole seconds since midnight UTC on January 1, 1970. iat records when the token was issued, exp the latest moment it should be accepted, and nbf the earliest moment it may be used. A verifier normally rejects a token before nbf and after exp, and may apply a clock-skew tolerance.

This decoder converts those raw seconds into three readable formats: UTC, your local timezone, and a human relative phrase like '2 hours ago'. That makes it obvious at a glance whether a token is current, already expired, or not yet valid.

JWTs vs Server Sessions

Session cookies trade a small identifier for server memory: the server stores the session and everything it knows about the user. JWTs invert that — the token carries the data, so any service that holds the verification key can trust it without a shared database. That statelessness is what makes them popular for API gateways and microservices.

The tradeoff is revocation. Killing a session cookie is a database delete; killing a JWT before it expires requires an additional revocation mechanism or a blacklist, because the token itself remains verifiable. That's why short expirations and refreshed access/refresh token pairs are standard practice.

For debugging integrations, this decoder helps you answer the practical questions: what does this token actually contain, when does it expire, and which claims will my server care about?

JWT Security Best Practices

Validate the algorithm. Servers should enforce an allow-list of accepted algorithms and never fall back to 'none'. Algorithm-confusion attacks occur when a server accepts a token signed with a public key but presented as an HMAC token using that same key as a secret.

Check every claim that matters. Verify iss and aud against expected values, reject anything past exp, and treat the payload as untrusted until the signature has been checked. Do not rely on a decoded token alone — decoding is trivial and proves nothing about authenticity.

Keep secrets out of the payload. Unlike some other token formats, a JWT is not encrypted; its payload is plain text. Sensitive data must never be placed in a JWT, because anyone holding the token can read every claim. The decoder you are looking at reads the same base64url a remote attacker would.

Frequently asked questions

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe string that carries claims about a subject between parties. It is built from three base64url-encoded sections — header, payload, and signature — joined by dots. JWTs are widely used for authentication and authorization in API integrations, single sign-on, and mobile apps.

Is it safe to paste a JWT into this decoder?

Decoding is entirely safe: a JWT payload is base64url-encoded plain text, not encrypted, so it can be read by anyone who holds the token. No token you paste here is sent to a server — everything runs locally in your browser. That said, a JWT may contain sensitive data, so treat it as confidential, the same way you would an access token.

Does this tool verify the JWT signature?

No. Signature verification requires the issuer's signing key, which lives on the server and is never sent to the browser. This decoder shows you the signature but does not validate it. A decoded token should be treated as untrusted until verified by the issuing service.

What does the JWT signature actually prove?

The signature proves the header and payload were signed by whoever holds the matching key. HMAC algorithms (HS256/384/512) use a shared secret held by issuer and verifier. Asymmetric algorithms (RS, ES, PS) use a private key to sign and a public key to verify. A valid signature tells verifiers the token was not tampered with after signing.

What is the difference between HS256 and RS256?

HS256 is a symmetric HMAC algorithm — issuer and verifier share a secret key. It is fast but the secret must be distributed to every verifier. RS256 is asymmetric RSA — the private key signs and the public key verifies. Anyone can verify an RS256 token using the public key, while only the issuer can create one.

What does 'exp' mean on a JWT?

exp (expiration time) is a Unix timestamp in seconds after which the token must not be accepted by a verifier. It is the primary clock for token lifecycle: short expirations reduce the window in which a stolen token can be reused, which is why most providers issue access tokens with expirations measured in minutes and refresh the token via a refresh token.

Why does my JWT payload say iat but not show a readable date?

iat is stored as a Unix timestamp — whole seconds since January 1, 1970 UTC — which is compact but not human-friendly. This decoder converts it for you into UTC, your local timezone, and a relative phrase, so you can tell at a glance when the token was issued.

What does the 'none' algorithm mean?

'none' means the JWT has no cryptographic signature. Anybody who can read the token can also modify its payload undetectably. It is only appropriate in contexts where integrity is guaranteed some other way, and production servers should generally reject 'none' tokens outright.

What are the standard JWT claims?

The registered claims are sub (subject), iss (issuer), aud (audience), exp (expiration), nbf (not before), iat (issued at), and jti (JWT ID). OpenID Connect adds azp, nonce, at_hash, auth_time, acr, and amr. This tool recognizes these and shows you what each one means.

Are JWTs encrypted?

No. A standard JWT (JWS) payload is base64url-encoded, not encrypted — anyone can decode it. There is a separate format, JWE (JSON Web Encryption), that encrypts the content, but it is far less common. Never put secrets or personal data in a plain JWT payload.

Can I use a JWT to make API calls?

Yes — that is the most common use. Send the token in the Authorization header as a Bearer token: 'Authorization: Bearer <token>'. The API verifies the signature, checks iss and aud, and enforces exp before honoring the claims. Browsers can store and attach these tokens, though the protection depends on where the token is kept.

Why do some tokens have a 'kid' header claim?

kid is a key identifier. Issuers rotate signing keys over time, and kid tells a verifier which public key from its key set to use when checking this particular token. Without kid, a verifier would have to try every key it knows.

What happens when a token is missing an exp claim?

Without exp, the token has no expiration and remains usable indefinitely if stolen. The security analysis here flags missing exp as a warning. Most production systems require exp, and if you are building an issuer, always set it.

Is the JWT data sent to any server by this tool?

No. The decoder runs entirely in your browser. The token you paste never leaves your machine. You can verify this yourself: disconnect your network and paste a token — the tool still works. This is the same privacy guarantee as the other TechFixGen security tools.