JWT Decoder

Decode and inspect JSON Web Tokens. Your token never leaves your browser.

How to Decode a JWT

A JSON Web Token (JWT) is a compact string that carries claims between two parties, most often an identity provider and an API. Decoding one takes a few seconds:

  1. Paste the token into the box above. A leading Bearer prefix and stray line breaks are removed for you.
  2. Read the header and payload. They appear instantly as formatted JSON, with the signing algorithm shown at the top.
  3. Check the time claims. The tool converts exp, iat and nbf into readable UTC and local dates and tells you whether the token has expired.
  4. Optionally verify the signature of HS256, HS384 or HS512 tokens by entering the shared secret.

Everything runs in your browser. The token is decoded with JavaScript on your device and nothing is uploaded or stored.

What Is a JSON Web Token?

A JWT, defined in RFC 7519, is made of three parts separated by dots: header.payload.signature. The header and the payload are JSON objects encoded with Base64URL, a variant of Base64 that swaps + and / for - and _ and drops the padding so the token is safe to put in a URL or an HTTP header. If you want to see what that encoding looks like on its own, try the Base64 Encoder/Decoder.

  • Header: says how the token is signed, usually with an alg field such as HS256 or RS256, and often typ and kid (key ID).
  • Payload: the claims. Registered claims include iss (issuer), sub (subject), aud (audience), exp, nbf, iat and jti (token ID). Applications add their own, such as roles or an email address.
  • Signature: computed over the header and payload with a secret or a private key, so the receiver can tell whether the token was altered.

Decoding Is Not Verifying

Reading a JWT needs no key at all, because the header and payload are not encrypted, only encoded. That means two things. First, never store secrets in a JWT. Second, a decoded token proves nothing by itself: an attacker can create a token with any claims they like. A server must verify the signature with the right key, check the algorithm it expects rather than trusting the header, and validate exp, nbf, iss and aud before accepting it.

Be especially wary of tokens with "alg": "none". They carry no signature, and this tool flags them. A correctly configured API rejects them.

Understanding JWT Time Claims

The exp, nbf and iat claims are NumericDate values: seconds since 1 January 1970 UTC, that is, Unix timestamps in seconds. A common bug is generating them in milliseconds, which puts the expiry thousands of years in the future. The table above warns you when a value looks like milliseconds. To convert any timestamp by hand, use the Timestamp Converter.

Frequently Asked Questions

Is it safe to paste my JWT into an online decoder?

It depends on the tool. This decoder runs entirely in your browser: the token is decoded with JavaScript on your device and is never sent to a server, which you can confirm by going offline and seeing it still works. Even so, a live token is a credential and can be replayed until it expires, so avoid pasting production tokens into any site you do not trust. Prefer expired or test tokens when you can.

Can this tool verify a JWT signature?

Yes for HMAC tokens (HS256, HS384 and HS512): enter the shared secret and the tool recomputes the signature with the Web Crypto API and compares it. Tokens signed with RSA or ECDSA (RS256, ES256, PS256 and similar) need the issuer's public key, which this tool does not handle. Remember that decoding a token is not the same as verifying it: anyone can read a JWT, but only the holder of the key can produce a valid signature.

Is a JWT encrypted?

A standard signed JWT (JWS) is not encrypted. The header and payload are only Base64URL-encoded, so anyone who has the token can read them. Never put passwords or other secrets in JWT claims. Encrypted tokens (JWE) have five dot-separated parts instead of three, and their payload cannot be read without the decryption key.

What do the exp, iat and nbf claims mean?

They are registered time claims defined in RFC 7519. exp is the expiration time, after which the token must be rejected. nbf (not before) is the time before which the token must not be accepted. iat is the time the token was issued. All three are NumericDate values: the number of seconds since 1 January 1970 UTC, so they are Unix timestamps in seconds, not milliseconds.

Why does my token fail to decode?

The usual causes are a truncated token, extra characters copied along with it, or a value that is not a JWT at all. A JWT must have exactly three parts separated by dots, and the first two must be Base64URL-encoded JSON objects. A leading Bearer prefix and any line breaks are stripped automatically.