fileformer
search⌘KtranslateENexpand_moreupload_fileConvert
Converters8 file families · 44 direct conversions
What changes in a conversionarrow_forward
home/developer-tools/jwt-decoder

JWT decoder

Paste a JSON Web Token to read its header and claims, see when it expires, and spot risky settings. Decoded in your browser: tokens are never sent or logged.

lockSafe for production tokens
encoded token280 chars
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQ4MjEiLCJuYW1lIjoiQWRhIExvdmVsYWNlIiwicm9sZSI6ImFkbWluIiwiaXNzIjoiaHR0cHM6Ly9hdXRoLmZpbGVmb3JtZXIuY29tIiwiYXVkIjoiZmlsZWZvcm1lci1hcHAiLCJpYXQiOjE3OTE2NzA3NTQsImV4cCI6MTc5MTY3NDM1NH0.Kx9v0q2yT3hQm8Rj1pZs7bW4nE6cL5aU0dF2gH3iJ4k
SamplesValidExpiredalg: none
error
check_circleNot expiredValid until 11 Oct 2026, 02:19 · in 50 min.
check_circleSigned with HS256Shared-secret signature (HMAC).
infoPayload is readable by anyoneNothing here is encrypted, never put secrets in a JWT.
check_circleShort lifetimeLives 1 hour: good practice.
header2 fields
algHS256signing algorithm
typJWTtoken type
payload7 claims
subuser_4821Subject
nameAda Lovelace
roleadmin
isshttps://auth.fileformer.comIssuer
audfileformer-appAudience
iat179167075411 Oct 2026, 01:19 · 10 min ago
exp179167435411 Oct 2026, 02:19 · in 50 min
signaturenot verified here
The signature proves the token wasn't changed, but checking it needs the secret or public key, which should stay on your server. Decoding only reads the contents.
~/three-parts

A JWT is three pieces, joined by dots.

The first two are just JSON, encoded as URL-safe Base64. Anyone can read them. Only the third, the signature, needs a key.

1 · headerWhat kind of tokenNames the signing algorithm and the token type. Read first, so the server knows how to check the signature.{ "alg": "HS256", "typ": "JWT"}
2 · payloadThe claimsFacts about the user and the token: who it’s for, what they can do, and when it expires.{ "sub": "user_4821", "exp": 1790003600}
3 · signatureProof it wasn’t changedA hash of parts 1 and 2 made with a secret key. Change one character of the payload and the signature no longer matches.HMACSHA256( header + "." + payload, secret)
~/registered-claims

The seven standard claims.

Three-letter names defined by the JWT standard (RFC 7519). All optional, but servers rely on them to decide whether to trust a token.

issIssuerWho created the token.
subSubjectWho it’s about: usually the user ID.
audAudienceWhich app it’s meant for.
expExpiresAfter this time it must be rejected.
nbfNot beforeNot valid until this time.
iatIssued atWhen it was created.
jtiToken IDUnique ID, to prevent replay.
…Custom claimsAnything else: name, role, permissions. Keep it small, tokens travel on every request.
~/handle-with-care

Four JWT mistakes that cause breaches.

gpp_badAccepting “alg: none”Some libraries once accepted unsigned tokens, letting attackers write their own claims: including admin: true.shieldExplicitly allow only the algorithms you use, and reject “none”.
gpp_badSecrets in the payloadThe payload is only encoded, not encrypted. Passwords, card numbers or API keys inside a JWT are visible to anyone who sees it.shieldKeep only IDs and permissions in the token. Look up sensitive data on the server.
gpp_badTokens that never expireA leaked token without exp stays valid forever, and JWTs can’t easily be revoked.shieldUse short-lived access tokens (5-60 min) with refresh tokens.
gpp_badStoring tokens where scripts can read themlocalStorage is readable by any script on the page, so one XSS bug can steal every token.shieldPrefer HttpOnly, Secure, SameSite cookies for browser sessions.
~/sign-it-yourself

Sign a real token, then change one claim and watch it fail.

Your browser's Web Crypto API signs the token below with the algorithm you pick. HMAC algorithms use your secret; the others use a key pair generated in this tab that never leaves it. It then verifies two tokens: the one it just made, and a copy with one claim changed but the original signature kept. Nothing is sent anywhere.

HS256HMAC + SHA-256HS384HMAC + SHA-384HS512HMAC + SHA-512RS256RSA PKCS#1 v1.5PS256RSA-PSSES256ECDSA P-256ES384ECDSA P-384EdDSAEd25519
SHARED SECRET224 of 256 bits
Too short for HS256: RFC 7518 requires at least 256 bits (32 bytes). Short secrets can be brute-forced offline from any single token.
PUBLIC KEY · JWK · what a server publishes
generating a key pair…
The private half stays in this tab and is thrown away when you leave. Verifiers only ever need the public key.
PAYLOAD · edit the JSON
1 · HEADER
{ "alg": "HS256", "typ": "JWT"}
2 · SIGNING INPUT · 237 ASCII byteseyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQ4MjEiLCJuYW1lIjoiQWRhIExvdmVsYWNlIiwicm9sZSI6ImVkaXRvciIsImlzcyI6Imh0dHBzOi8vYXV0aC5maWxlZm9ybWVyLmNvbSIsImF1ZCI6ImZpbGVmb3JtZXItYXBwIiwiaWF0IjoxNzkxNjcxMzU0LCJleHAiOjE3OTE2NzIyNTR9
3 · SIGNATURE · 32 bytes1.3 ms to sign14fa41490e5dada4ea52198df828bef23da5153989537a15babb4a3c9b576553An HMAC over the signing input. Anyone who can verify it can also create one, so every verifier holds the secret.
THE TOKEN · 281 charactersnorthOpen in the decodereyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQ4MjEiLCJuYW1lIjoiQWRhIExvdmVsYWNlIiwicm9sZSI6ImVkaXRvciIsImlzcyI6Imh0dHBzOi8vYXV0aC5maWxlZm9ybWVyLmNvbSIsImF1ZCI6ImZpbGVmb3JtZXItYXBwIiwiaWF0IjoxNzkxNjcxMzU0LCJleHAiOjE3OTE2NzIyNTR9.FPpBSQ5draTqUhmN-Ci-8j2lFTmJU3oVurtKPJtXZVM
verifiedToken as signedThe signature matches the header and payload byte for byte.open in decoder
gpp_badSame signature, role changed from "editor" to "superadmin"Rejected: changing one claim changes the signing input, so the old signature no longer fits. Only someone with the secret can make a new one.open in decoder
~/what-the-server-checks

Decoding is not validating. Here's everything a server must check.

This runs the checks in the order RFC 8725, the JWT best-practice document, recommends, on whatever token is in the decoder at the top of the page. Set the server's expectations on the left. Move the clock to see expiry, not-before and leeway in action.

EXPECTED ISSUER (iss)
THIS SERVER’S AUDIENCE (aud)
ALLOWED ALGORITHMS
HS256HS384HS512RS256PS256ES256ES384EdDSA
CLOCK LEEWAY60 s
SERVER CLOCKnow
server time 2026-10-10T22:29:14Z · 1791671354
shieldAccepted, if the signature verifiesEvery check this page can run passed. The signature still needs the issuer’s key.
01check_circleStructureThree parts. The header and payload both decode to JSON objects.
02check_circleExplicit typetyp is "JWT".
03check_circleAlgorithm allowlistHS256 is allowed. The server should still choose how to verify from its own configuration for this key, not from the header.
04check_circleKey selectionNo kid, so the server uses its one configured key.
05helpSignatureNeeds the issuer’s key, which this page doesn’t have. Make a token in the signing lab and open it in the decoder to see this step run.
06check_circleExpiry (exp)Valid for another 51 min, counting 60 s of leeway for clock drift.
07check_circleIssued at (iat)Issued 10 min before the server’s clock.
08check_circleIssuer (iss)Matches exactly.
09check_circleAudience (aud)The token lists this server as an audience.
~/reference

Every JWS algorithm, tested in your browser.

The registered signature algorithms from RFC 7518 and RFC 8037, with the signature size each adds to every token. The last column was found by asking this browser's Web Crypto API to create a key for each one.

algmethodkeysignaturebase64url charsRFC 7518 statusWeb Crypto
HS256HMAC with SHA-256shared secret, ≥ 256 bits32 bytes43Required…
HS384HMAC with SHA-384shared secret, ≥ 384 bits48 bytes64Optional…
HS512HMAC with SHA-512shared secret, ≥ 512 bits64 bytes86Optional…
RS256RSASSA-PKCS1-v1_5 with SHA-256RSA, ≥ 2048 bits256 bytes342Recommended…
PS256RSASSA-PSS with SHA-256 and MGF1RSA, ≥ 2048 bits256 bytes342Optional…
ES256ECDSA, P-256 curve, SHA-256EC P-25664 bytes86Recommended+…
ES384ECDSA, P-384 curve, SHA-384EC P-38496 bytes128Optional…
EdDSAEd25519 (RFC 8037)OKP Ed2551964 bytes86RFC 8037…
noneNo signature at allnone00Optional, never acceptn/a

Header parameters, and which ones to distrust

algAlgorithmHow the token was signed. Check it against your own allowlist; never let it choose the verification method on its own.check it
typTypeMedia type of the whole token, such as JWT or at+jwt. Explicit types stop one kind of token being used as another.safe
ctyContent typeSet to JWT only when the payload is itself a nested JWT.safe
kidKey IDPicks a key from your own key set. Treat it as an untrusted string: it has been used for SQL injection and path traversal.check it
jkuJWK Set URLA URL to fetch keys from. If honoured, an attacker hosts their own key and signs anything.distrust
jwkEmbedded keyA public key inside the token. Verifying with it proves only that the token matches itself.distrust
x5uX.509 URLLike jku, but for certificate chains. Same risk.distrust
x5cCertificate chainCertificates inside the token. Only safe if you validate the chain against your own trusted roots.check it
x5t#S256Certificate thumbprintSHA-256 of the signing certificate, used to look it up.safe
critCriticalLists extensions that must be understood. Reject the token if you don’t support every one.check it
b64Base64url payloadRFC 7797: false means the payload is not encoded. Must be listed in crit.check it

From draft to best practice

2010First JWT draftMike Jones and others publish the JSON Web Token draft at the IETF.
2015Critical JWT library flawsTim McLean shows libraries accepting alg none, and RS256 public keys used as HS256 secrets.
2015RFC 7515-7519JWS, JWE, JWK, JWA and JWT are published together as standards.
2016RFC 7797An option to sign payloads without Base64url-encoding them.
2017RFC 8037Ed25519 and Ed448 signatures arrive as EdDSA.
2020RFC 8725JWT Best Current Practices: algorithm allowlists, explicit typing and audience checks.
2021RFC 9068A standard profile for OAuth 2.0 access tokens, with typ at+jwt.
2022Psychic signaturesCVE-2022-21449: some Java versions accepted ECDSA signatures of all zeros, so ES256 tokens could be forged.

More auth & encoding tools

For building and debugging login flows.

All developer tools →