JWT Decoder
Decode and inspect JSON Web Tokens, then verify a JWT signature against your own secret or public key — HS256, RS256, ES256, EdDSA and the rest of the RFC 7518 algorithms. Everything runs in your browser — no token or key is ever sent anywhere.
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}Signature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Supported signature algorithms
HS256HMAC with SHA-256HS384HMAC with SHA-384HS512HMAC with SHA-512RS256RSASSA-PKCS1-v1_5 with SHA-256RS384RSASSA-PKCS1-v1_5 with SHA-384RS512RSASSA-PKCS1-v1_5 with SHA-512PS256RSASSA-PSS with SHA-256PS384RSASSA-PSS with SHA-384PS512RSASSA-PSS with SHA-512ES256ECDSA on P-256 with SHA-256ES384ECDSA on P-384 with SHA-384ES512ECDSA on P-521 with SHA-512EdDSAEdDSA (Ed25519)Ed25519EdDSA (Ed25519)noneUnsecured — no signatureEd25519 verification depends on browser support for the Web Crypto Ed25519 curve.
Frequently asked questions
How do I decode a JWT?
Paste the token into the box. It is split on its dots and the header and payload are Base64url-decoded and pretty-printed immediately, with the registered claims labelled and timestamps rendered as readable dates. No key or secret is needed to read a token — only to verify it.
Is decoding a JWT the same as verifying it?
No, and conflating the two is a serious security bug. Decoding just Base64-decodes text that anybody holding the token can read and edit. Verifying checks the signature against the issuer’s key, which is what proves the claims have not been tampered with. Never trust a claim from a token your server has not verified.
Why does my JWT have three parts separated by dots?
A JWT is header.payload.signature. The header names the signing algorithm and key, the payload carries the claims, and the signature covers the first two so any change to them invalidates it. The first two parts are only Base64url-encoded, not encrypted — anyone with the token can read them.
What do the exp, iat, nbf, iss, aud and sub claims mean?
They are the registered claims from RFC 7519: iat is when the token was issued, nbf the earliest moment it may be accepted, and exp when it expires, all as Unix timestamps in seconds. iss identifies the issuer, aud the intended recipient and sub the subject, usually the user ID. Each one is labelled and its dates spelled out here.
Why does the signature not verify with my secret?
Usually the algorithm and the key do not match. An HS256 token needs the shared secret exactly as bytes, including any trailing newline your editor added, while an RS256 or ES256 token needs the issuer’s public key in PEM form, not the private key and not a certificate fingerprint. A token copied with a line break or a missing final character will also fail.
Is it safe to paste a real token here?
The token never leaves your browser — it is decoded locally and no request is made. Still treat any live token as a password: it grants whatever access it represents until it expires, so avoid pasting production tokens on a shared or managed machine, and revoke or let expire anything you have handled loosely.