JWT Decoder

What is a JSON Web Token?

A JSON Web Token (JWT) is a compact, URL-safe token format used for securely transmitting information between parties. It consists of three parts: a header (algorithm and type), a payload (claims and data), and a signature. This tool decodes and verifies JWTs entirely in your browser; your token and keys aren't sent to a server.

The three parts of a JWT

A JSON Web Token has three parts separated by dots: the header, the payload, and the signature. The header and payload are Base64URL-encoded JSON, so anyone can decode and read them — they are not secret. The header names the signing algorithm (such as HS256 or RS256), while the payload carries the claims: statements about the user and the token, like who issued it and when it expires.

The third part, the signature, is what makes a token trustworthy. It is computed from the header, the payload, and a secret or private key. If even one character of the header or payload is changed, the signature no longer matches, and verification fails.

Decoding is not the same as verifying

Decoding a JWT simply reveals its contents — it does not prove the token is genuine. Because the payload is only Base64URL-encoded, never trust its claims until the signature has been verified against the key that signed it. This tool decodes tokens instantly in your browser and verifies signatures with the browser's Web Crypto API, using the secret for HS256, HS384, and HS512 or the public key for RS, PS, ES, and EdDSA tokens.

Verifying tokens safely

Always validate the signature with the issuer's key before trusting any claim, and check the exp and aud claims so an expired token, or one meant for a different service, is rejected. Prefer short-lived access tokens paired with refresh tokens over long-lived ones, and never place passwords or secrets in the payload, since anyone can read it.

How to decode and verify a JWT

1Paste the token. Paste a JWT, or a whole Authorization header value; the Bearer prefix and any line breaks are removed. The header and payload are decoded immediately.
2Read the claims and times. Standard claims are labelled, and iat, nbf, and exp are shown in your time zone with how long ago or how soon they are, along with whether the token is expired or not valid yet.
3Verify the signature. Switch to Verify and enter the secret for HS256, HS384, or HS512 (as text or Base64), or the public key for RS, PS, ES, or EdDSA tokens as PEM or a JWK / JWK Set.

Examples

A decoded payload

The middle segment of a token, Base64URL-decoded.

Input

eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBZGEiLCJleHAiOjE5MDAwMDAwMDB9

Output

{
  "sub": "12345",
  "name": "Ada",
  "exp": 1900000000
}

A complete token

Three Base64URL parts joined by dots. Verify it with the HS256 secret devtoolbox-sample-secret.

Input

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBZGEiLCJpYXQiOjE3NjcyMjU2MDB9.ewt67C2x4PozuRRMd0aXqJ3ZzxiJqkXu_0Z2CmOmgHQ

Output

{
  "header": {
    "alg": "HS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "12345",
    "name": "Ada",
    "iat": 1767225600
  }
}

Standard JWT claims

Registered claim names defined by RFC 7519.

Claim	Meaning
iss	Issuer — who created the token
sub	Subject — who the token is about
aud	Audience — who the token is intended for
exp	Expiration time (Unix seconds)
nbf	Not before — valid only after this time
iat	Issued at (Unix seconds)
jti	JWT ID — a unique identifier for the token

Frequently asked questions

Is a JWT encrypted?

No. A standard signed JWT is encoded, not encrypted. The header and payload are only Base64URL-encoded, so anyone can read them. Never put secrets in a JWT payload unless you are using an encrypted JWE.

Is it safe to decode my token here?

Yes. Decoding and verification run entirely in your browser, and your token and any secret or key you enter aren't sent to a server. The only exception is the Share link button, which uploads the decoded header and payload (never the token, signature, or key) when you click it, so don't use it for tokens that carry personal data.

What does the signature do?

It proves the token was issued by someone holding the signing key and that the header and payload have not been altered. Changing any part of the token invalidates the signature.

Which algorithms can it verify?

HS256, HS384, and HS512 with a shared secret; RS256, RS384, RS512, PS256, PS384, and PS512 with an RSA public key; ES256, ES384, and ES512 with an EC public key; and EdDSA (Ed25519). Paste public keys as PEM (BEGIN PUBLIC KEY) or as a JWK or JWK Set, which is matched to the token by its kid. Unsigned tokens (alg: none) have nothing to verify.

What does the exp claim mean?

exp is the expiration time as a Unix timestamp in seconds. From that moment on the token must be rejected. iat records when it was issued.

What does “Not valid yet” mean?

The token has an nbf (not before) claim set in the future. RFC 7519 says it must not be accepted before that time, just as it must not be accepted at or after its exp time.

What is the difference between HS256 and RS256?

HS256 signs with a single shared secret using HMAC-SHA256. RS256 signs with an RSA private key and is verified with the matching public key, which is better when many parties need to verify but not issue tokens.

Can someone edit a JWT?

They can change the readable header and payload, but without the signing key they cannot produce a valid signature, so a verifying server will reject the modified token.

Where should a browser store a JWT?

Prefer an HttpOnly, Secure cookie so scripts cannot read the token, which limits exposure if your site has a cross-site scripting flaw. Storing tokens in localStorage is convenient but readable by any script on the page.

Related tools