JWT Encoder / Decoder

Segment	Role	Encoding	Example
1	header (alg, typ)	Base64URL	eyJhbGciOiJIUzI1NiJ9
2	payload (claims)	Base64URL	eyJzdWIiOiIxMjM0NTY3ODkwIn0
3	signature	Base64URL	SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV…
exp	expiration	Unix (s)	1793827200 → 2026-11-04
HS256	HMAC + SHA-256	shared secret	32 bytes minimum
RS256	RSA + SHA-256	PEM public key	asymmetric verification
« + » in Base64	—	Base64URL	replaced by « - »
« / » in Base64	—	Base64URL	replaced by « _ »

What does « decode a JWT » mean?

Decode a JWT (« jwt decode », « decode jwt online ») means cutting the string at the dots, then decoding each segment from Base64URL to recover the original JSON. No key is needed: header and payload are simply encoded, not encrypted. That is exactly the intent behind « jwt payload decoder » or « decode jwt without verify » — see what the token contains, without pretending it is authentic.

Be sure to tell the two actions apart. Reading a JWT proves nothing: anyone can forge a token with an attractive payload and sign it with their own secret. Verify the signature proves the content was not modified by a third party. A decoder that shows « admin: true » without a signature check tells you a story, not a fact.

The three segments of a JWT

The string splits into exactly three dot-separated parts: header.payload.signature. The header contains at least alg and typ, sometimes kid to indicate which key was used. The payload carries the claims, these key-value pairs whose registry is maintained by the IANA. The signature covers the first two segments concatenated exactly as written — the slightest change to a space or a character breaks the comparison.

The whole difficulty is that these segments are Base64URL rather than Base64: the plus sign becomes a hyphen, the slash becomes an underscore, and the padding = disappears. A standard Base64 decoder will therefore fail on a valid JWT. The « Base64URL vs standard Base64 » table in the reference tab shows exactly these substitutions.

How to verify a signature: HS256, RS256, ES256

For an algorithm HMAC — HS256, HS384, HS512 — the same secret is used to sign and to verify: the tool recalculates HMAC(secret, base64url(header) + "." + base64url(payload)) and compares the result with the carried signature. This is the most common case, and also the most dangerous: any service holding the secret can issue a token. A secret under 32 bytes, reused across environments, is enough to compromise the whole chain.

For the algorithms asymmetric — RS256, RS384, RS512, ES256, ES384, ES512, PS256 — you only need the public key to verify, which lets you check a token issued by a third party without ever sharing its signing secret. Paste the key in PEM format -----BEGIN PUBLIC KEY----- (SPKI); the raw output of an OpenSSL export is directly usable. For ES256, the signature is in raw r||s format, the one WebCrypto expects.

Finally, watch out for thealg confusion : if your service expects RS256 but accepts a token whose header declares HS256, an attacker will sign with the public key — now an HMAC key — and pass verification. Pin the expected algorithm server-side, never read it from the token itself.

exp, iat, nbf: the timestamps that trip you up

These three claims are Unix seconds, with no milliseconds and no time zone: iat 1516239022 means 2018-01-17T21:30:22Z. Two mistakes keep coming back: comparing against a date in milliseconds (a value ten thousand times too large) and reading a timestamp as local rather than UTC. The « Expiration » tab converts both ways, showing ISO 8601, the local date and the time remaining or elapsed — enough to spot an « already expired » token down to the second.

Extending the lifetime does not raise security: a exp pushed-back value changes the displayed value, not the signature. If you must reissue, re-sign the token with the secret or the private key — that is exactly what the « Encode » tab is for.

Base64URL: why standard decoders fail

Base64URL (RFC 4648 §5) uses the alphabet A-Z a-z 0-9 - _ and allows no padding. A 20-character payload often produces a length that is not a multiple of four once the = : is normal, not corruption. The characters - and _ are ambiguous to the human eye, which explains half of the « broken tokens » reported. Our decoder accepts both alphabets, mixed case, optional padding and a Bearer.

Security: what a JWT does not do

A JWT gives you neither confidentiality nor revocation. The payload is readable by anyone: never put an email, an internal role or personal data you would not send in the clear. And a signed token stays valid until exp even after logout — you need a revocation list, some jti server-side tracking, or short lifetimes with a refresh token. Good practice: exp short (10 to 15 minutes), iat controlled, nbf aligned with iat, aud and iss verified on receipt.

Recommended for

Back-end and front-end developers (OAuth 2.0, OpenID Connect, REST APIs), integrators and DevOps (identity infrastructure, JWKS, key rotation), QA testers and pentesters (claim rewriting, alg confusion, expiration), system administrators (debugging an unexplained 401), students (understanding Base64URL and WebCrypto), and anyone who needs an online JWT decoder fast, complete and private — complemented by theBase64 encoder decoder, theURL encoder decoder and the JSON formatter.

100% local JWT decoder: your token never leaves your computer

Unlike classic online JWT decoders, no string is transmitted: decoding, signature verification and encoding all run in your browser via WebCrypto, with no third-party library and no network request. That is what lets you inspect a real session token, a staging key or an internal service token safely, even offline or on a public network. History and your last input are kept locally (localStorage) and stay on your device.

The license Volade Premium adds optional, encrypted cloud sync independent of the tool — everything else stays free and unlimited, with no sign-up.