JWT Decoder

๐Ÿ’ป Web & Developer

JWT Decoder

Paste a JSON Web Token to instantly see its header, payload, and expiry status โ€” decoded entirely in your browser.

Advertisement
๐Ÿ”‘
JWT Decoder

This decodes the token's contents โ€” it doesn't verify the signature, since that requires the secret key.

Paste the full token, including all three dot-separated parts
That doesn't look like a valid JWT โ€” it should have three parts separated by periods.
Security note: Decoding only reveals the contents โ€” it does NOT verify the signature is valid or that the token hasn't been tampered with. Never trust a decoded JWT's contents without verifying the signature server-side using the correct secret or public key.
Advertisement

What Is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties โ€” most commonly used for authentication and authorization in web APIs. A JWT has three Base64URL-encoded parts separated by periods: header, payload, and signature.

The Three Parts

header.payload.signature

Header: algorithm and token type
Payload: the actual claims (user ID, expiry, custom data)
Signature: verifies the token hasn't been tampered with

The header and payload are just Base64URL-encoded JSON โ€” anyone can decode and read them without any secret key, which is exactly what this tool does. The signature, however, requires the secret (or private key) to verify, and can't be checked by a simple client-side decoder.

How to Use This Decoder

Paste your full JWT (all three parts, separated by periods) into the box. The decoder splits it, Base64URL-decodes the header and payload, and displays both as readable JSON. If the payload contains an "exp" (expiration) claim, it also shows whether the token is currently valid or expired.

Decoding Is Not Verifying

This is the single most important thing to understand about JWTs: anyone can decode and read a token's contents without any special access, because the header and payload are just encoded, not encrypted. Decoding tells you what a token claims; verifying tells you whether you can trust that claim. Only a server with the correct secret key (or public key, for asymmetric algorithms) can actually verify a token's signature is valid.

๐Ÿ’ก Never put sensitive secrets directly in a JWT payload โ€” since anyone can decode it, treat the payload as visible information, not protected information. Sensitive data should stay server-side, referenced by an ID in the token instead.

Common JWT Claims

  • sub: the subject โ€” typically a user ID
  • iat: issued-at timestamp
  • exp: expiration timestamp โ€” when the token stops being valid
  • iss: issuer โ€” who created the token
  • aud: audience โ€” who the token is intended for

Common Algorithms in the Header

The header's "alg" field tells you how the token is signed โ€” HS256 (HMAC with SHA-256) is common for simpler setups using a shared secret, while RS256 (RSA with SHA-256) is common when a public/private key pair is used, often for verifying tokens across multiple services without sharing a secret.

Where This Fits

Pair this with our Base64 encoder for general encoding tasks, and our JSON formatter if you need to clean up the decoded payload further.

Frequently Asked Questions

Can anyone read the contents of a JWT?
Yes โ€” the header and payload are encoded (not encrypted), so anyone with the token can decode and read them, even without the secret key. Only the signature requires the secret to verify.
Does this tool verify if a JWT is valid?
No โ€” it decodes the contents only. Verifying the signature requires the secret or public key used to sign it, which isn't something a generic client-side decoder can or should have access to.
Is it safe to put sensitive data in a JWT payload?
No โ€” treat JWT payloads as visible to anyone who has the token. Sensitive data should be kept server-side and referenced by an ID, not embedded directly in the token.
What does the "exp" claim mean?
It's the expiration timestamp (in Unix seconds) after which the token should no longer be accepted by a server, regardless of whether the signature is still technically valid.
Why does my token show as expired here but my app still accepts it?
Some applications don't strictly enforce the exp claim, or use refresh token logic that issues new tokens transparently โ€” this decoder simply reports what the claim says, not how any specific server handles it.
Is my token sent anywhere when I paste it here?
No โ€” everything is decoded locally in your browser using JavaScript. Nothing is transmitted to a server, which matters since tokens can contain sensitive session information.
Advertisement

Scroll to Top