JWT Decoder & Verifier

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format used to securely transmit information between parties as a JSON object. JWTs are widely used for authentication and authorization in web applications and APIs.

A JWT consists of three Base64URL-encoded parts separated by dots:

Header.Payload.Signature

JWT Structure

Part	Contains	Example
Header	Algorithm & token type	{"alg":"HS256","typ":"JWT"}
Payload	Claims (user data)	{"sub":"123","name":"Alice","iat":1516239022}
Signature	Integrity verification	HMACSHA256(base64(header)+"."+base64(payload), secret)

Standard Claims

Claim	Name	Description
`iss`	Issuer	Who issued the token
`sub`	Subject	Who the token refers to (usually user ID)
`aud`	Audience	Who the token is intended for
`exp`	Expiration	Unix timestamp — token is invalid after this time
`nbf`	Not Before	Unix timestamp — token is invalid before this time
`iat`	Issued At	Unix timestamp — when the token was issued
`jti`	JWT ID	Unique identifier for this token

Supported Algorithms

Algorithm	Type	Key	Notes
HS256	HMAC-SHA256	Shared secret	Most common — this tool can verify
HS384	HMAC-SHA384	Shared secret	This tool can verify
HS512	HMAC-SHA512	Shared secret	This tool can verify
RS256	RSA-SHA256	Public/private key	Decode only (verification requires public key)
ES256	ECDSA-SHA256	Public/private key	Decode only

Security Warning

Never paste production JWTs containing sensitive user data into online tools you don't control. This tool runs entirely in your browser — no data is sent to any server — but always be careful with real tokens.

Common JWT Errors and What They Mean

Error / Symptom	Likely Cause	Fix
`invalid signature`	Wrong secret/key, or the token was re-signed after the payload was edited	Confirm the exact secret used by the issuer; check for trailing whitespace or encoding mismatches
`jwt expired`	`exp` claim is in the past relative to server time	Check for clock drift between issuer and verifier, or re-authenticate to get a fresh token
`jwt malformed`	Token doesn't have exactly 3 dot-separated Base64URL parts	Check for truncation (e.g. a cookie or header size limit cutting off the token)
`invalid algorithm`	Header `alg` doesn't match what the verifying library expects	Never accept `alg: none` from client input — this is a known JWT bypass technique
Payload decodes but looks like garbage	Token is actually a JWE (encrypted), not a signed JWT (JWS)	JWE has 5 dot-separated parts, not 3, and requires a decryption key, not just a verification secret

Frequently Asked Questions

Is it safe to paste a real JWT into this decoder?

This tool decodes and verifies entirely in your browser using the Web Crypto API — the token and secret are never transmitted to any server. That said, treat production tokens carefully: a decoded JWT's payload is plainly readable, so avoid pasting tokens into any tool while screen-sharing or on a shared machine.

Why can this tool verify HS256 but not RS256 signatures?

HS256/384/512 use a single shared secret, so verification just means re-computing the HMAC with the secret you provide. RS256 and ES256 use a public/private key pair — verifying them requires the issuer's public key, not a secret, so this tool decodes RS256/ES256 tokens but does not verify their signature.

Why does my JWT show as expired when I think it shouldn't be?

The exp claim is a Unix timestamp in seconds, compared against the current time in UTC. A common cause of unexpected expiry is a server issuing tokens with a clock that has drifted, or code that multiplies or divides the timestamp by 1000 by mistake when converting between seconds and milliseconds.

Can a JWT be edited without invalidating it?

No — the header and payload can be decoded and read by anyone, but any change to them changes the signature check. If the signing secret or private key is unknown, an edited token will fail verification. This is why sensitive data should still be encrypted, not just signed, if it must not be readable.