JWT Decoder
Decode a JSON Web Token to inspect its header and payload claims. Performs base64url decoding only and does not verify the token signature.
JWT Decoder
Calculator
Adjust values & calculateEnter your values below. Every result is computed in your browser — no data is sent to any server.
Formula: JWT = header.payload.signature (base64url encoded)
Worked example — Algorithm, claims, expiry
Formula
JWT = header.payload.signature (base64url encoded)
Decode JSON Web Tokens to inspect header and payload claims. Does NOT verify signatures.
Worked Examples
Example 1: Sample JWT
Problem:Paste a JWT token
Solution:Decodes header (algorithm) and payload (claims)
Result:Algorithm, claims, expiry
Frequently Asked Questions
Is it safe to paste JWTs here?
Yes — this runs entirely in your browser. Nothing is sent to any server. However, never share JWTs publicly as they may contain sensitive claims.
What is a JWT and how is it structured?
A JSON Web Token is a compact, URL-safe token with three Base64URL-encoded parts separated by dots: header (algorithm and token type), payload (claims like user ID and expiry), and signature (used to verify the token's integrity).
Does this tool verify the JWT signature?
No. Verifying a JWT signature requires the secret key or public key that the issuing server used to sign it. This decoder only parses the header and payload, which are base64-encoded but not encrypted and can be read by anyone who has the token.
When would I use a JWT decoder?
Use it during API development to inspect authentication tokens, debug expired token issues by checking the exp claim, verify which claims are included in an identity provider's tokens, or troubleshoot authorization failures in microservices.
What do the registered claims iss, sub, aud, exp, nbf, iat and jti mean?
RFC 7519 reserves a small set of claim names so independent systems agree on them. iss names the issuer, sub identifies the subject the token is about, and aud lists the intended recipients, which a verifier should check against itself. exp is the expiry, nbf the earliest moment the token is valid and iat when it was issued. jti is a unique identifier, useful for spotting replay or denylisting one token. Everything else in the payload is a public or private claim.
Why do exp and iat appear as large integers?
The time claims use NumericDate, a count of seconds since the Unix epoch of 1 January 1970 UTC, so they are plain integers rather than formatted dates. JavaScript Date works in milliseconds, which is why converting them requires multiplying by 1000. A frequent bug is writing Date.now() straight into exp: the value is a thousand times too large and places expiry tens of thousands of years out, so the token never expires. Verifiers usually allow a small leeway on exp and nbf for clock skew.
What is the difference between HS256 and RS256?
HS256 is HMAC with SHA-256 and a single shared secret, so whoever can verify a token can also mint one; that is acceptable when issuer and verifier are the same service. RS256 signs with an RSA private key and verifies with the matching public key, so any number of services or third parties can validate without being able to forge, which is why identity providers prefer it. ES256 does the same job with an ECDSA key on the P-256 curve and produces much shorter signatures.
Why must a verifier ignore the alg value inside the token?
Because the header is supplied by whoever sent the token. Early libraries accepted an alg of none and skipped verification entirely, and others could be steered into treating an RS256 token as HS256 and using the issuer public key, which is not secret, as the HMAC key. Either way an attacker writes their own claims. The rule that came out of it is that the verifier pins the algorithms it accepts and picks the key from its own trusted set, treating the header only as a hint.
How can a JWT be revoked before it expires?
Not directly. A signed token is self-contained, so there is no server-side session to delete and a stolen token stays valid until exp passes. The workable answers are all indirect: keep access token lifetimes short and put the long life in a refresh token that can be withdrawn, hold a denylist of jti values until they expire anyway, stamp a per-user token version or not-before timestamp that validation checks, or rotate the signing key to invalidate every outstanding token at once.
What is a JWKS endpoint and what is the kid header for?
A JSON Web Key Set, defined by RFC 7517, is a document of public keys an issuer publishes at a fixed URL, advertised as jwks_uri in OpenID Connect discovery. Verifiers fetch and cache it rather than hard-coding a key. The kid field in a token header names which key of that set signed it, so an issuer can publish a new key, start signing with it and retire the old one without breaking clients mid-rotation. A verifier that ignores kid breaks the moment keys rotate.
Background & Theory
History
Reviewed for accuracy by Daniel Agrici, Founder & Lead Developer · Editorial policy
Related Calculators
📋JSON Formatter
Format and validate JSON
🆔UUID Generator
Generate unique identifiers
🔒Hash Generator
Generate MD5, SHA hashes
🧮Base64 Encoder Decoder
Calculate base64 encoder decoder with inputs, formulas, and instant results.
🧮Base64 Encode Decode Tool
Encode text to Base64 or decode Base64 strings back to plain text instantly.
🧮URL Encode Decode Tool
Encode special characters for URLs or decode percent-encoded URL strings.
🧮HTML Entity Encoder
Calculate html entity encoder with inputs, formulas, and instant results.
🧮Base64 Encode & Decode Calculator
Calculate base64encode decode with inputs, formulas, and instant results.