Developer Tools

JWT Decoder

Decode and inspect JSON Web Tokens. View header, payload, signature, and expiry — 100% in your browser.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkhhZml6IEhhbmlmIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ALG: HS256

Header

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

{
  "sub": "1234567890",
  "name": "Hafiz Hanif",
  "iat": 1516239022
}

Signature

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The signature is verified server-side using the secret key. This tool cannot verify signatures without the key.

The three parts of every JWT

A JWT is just three Base64URL-encoded chunks joined by dots: header.payload.signature. Each part has one job.

  • Header — declares the algorithm (HS256, RS256, etc.) and that this is a JWT
  • Payload — the actual data: user ID, roles, expiry, custom claims
  • Signature — cryptographic seal that proves the token wasn't tampered with

JWTs are NOT encrypted

Anyone with the token can read the header and payload — they're just Base64-encoded, not secret. Never put passwords, credit card numbers, or anything truly sensitive in a JWT payload. Use it for identifiers and non-secret metadata only.

The standard claims (and what they mean)

The JWT spec reserves short three-letter claim names. You'll see these constantly:

  • subSubject. Usually the user ID this token represents.
  • issIssuer. Who created the token (your auth server's identifier).
  • audAudience. Who the token is intended for (e.g., your API).
  • expExpiry as a Unix timestamp. The tool above shows this in human time and warns if expired.
  • iatIssued at (Unix timestamp). When the token was created.
  • nbfNot before. Token isn't valid until this time.
  • jtiJWT ID. Unique identifier, useful for blacklisting.

Decoder vs verifier

This tool decodes the token so you can read its contents. Verifying that the signature is valid requires the secret key — that has to happen on your server, never in the browser.

FAQ

Can someone read my JWT if they get hold of it?

+

Yes — the header and payload are just Base64. Anyone can decode them. That's why you should never include passwords or secrets in a JWT.

What an attacker cannot do is forge a new valid token without the signing secret. If a token leaks, treat it like a session cookie that needs to be revoked.

Why don't I need a key to decode here?

+

Decoding is just Base64 + JSON parsing — no key needed. Verifying the signature is what needs the key, and that's done by your backend.

Is my token sent anywhere?

+

No. The decoder runs entirely in your browser using JavaScript. Your token never leaves your device — safe to paste production tokens here for debugging.

What's the difference between HS256 and RS256?

+

HS256 uses a shared secret — both signer and verifier need it. Simpler but means everyone who can verify can also forge.

RS256 uses an asymmetric key pair — private key signs, public key verifies. Better for distributed systems where many services need to verify.

Keep exploring

Related tools

Browse all 38+ tools