JWT Decoder Online — Decode Header, Payload & Claims
Paste a JSON Web Token to decode its header, payload, and standard claims instantly. Get a live expiration verdict, RFC 7519 claim labels, and Unix-to-ISO date conversion. Free, no signup, and 100% in-browser — your token never leaves your device.
JWT Decoder & Debugger workspace
Zero Network, Zero Logging
Decoding happens entirely in your browser. We never send your token, header, payload, or signature to any server. Safe for production tokens during debugging.
Instant Expiration Verdict
Automatic check of `exp` and `nbf` claims with human-readable countdowns. Spot expired tokens at a glance instead of squinting at Unix timestamps.
Standard Claim Definitions
RFC 7519 reserved claims (iss, sub, aud, exp, nbf, iat, jti) are highlighted with inline descriptions so you can teach your team or audit a token quickly.
Algorithm + Type Surfacing
Header `alg` and `typ` are extracted and labelled. Identify HS256, RS256, ES256, EdDSA, and risky `alg: none` tokens before they hit your auth middleware.
JWT Decoder: Read the Header, Payload & Claims of Any Token
A JWT decoder splits a JSON Web Token on its two dots into three segments and base64url-decodes the header and payload back to readable JSON. Paste a header.payload.signature string and this tool shows the algorithm, every claim, a live expiration verdict, and ISO dates for exp, nbf, and iat. It runs 100% in your browser, free, with no upload. Decoding is not verification.
How to use the JWT decoder
- Copy the token value — usually the part after
Authorization: Bearerin DevTools or a backend log. Drop theBearerprefix and any trailing newline. - Paste it into the box above. The decoder trims whitespace and splits on the dots automatically.
- Read the Header for
algandtyp, then the Payload for the claims. - Check the status verdict — "Valid for 2h more", "Expired 5m ago", or "not-yet-valid" when
nbfis in the future. - Copy any individual segment to your clipboard, then verify the token cryptographically in your own backend.
What is a JWT and how does decoding work?
A JSON Web Token is a compact, URL-safe credential defined by RFC 7519. It carries claims as a JSON object split into three dot-separated segments: a header declaring the algorithm (alg) and type (typ), a payload of claims, and a signature. Each segment is base64url-encoded (RFC 4648 §5): a URL-safe Base64 that uses - instead of +, _ instead of /, and drops = padding.
To decode, this tool reverses that: it swaps -→+ and _→/, restores the padding, runs the browser's atob, then UTF-8 decodes the bytes with TextDecoder so non-ASCII claim values (names, emoji) survive. The header and payload are then JSON.parsed. The signature is left untouched — decoding never proves authenticity.
The payload is base64url-encoded, not encrypted. Anyone holding the token can read every claim with no key.— The signature guarantees integrity, not confidentiality. Never store passwords, API keys, or PII in a JWT payload.
The signature is what makes a token tamper-evident. For HS256 it is an HMAC-SHA256 (RFC 2104) over header.payload using one shared secret. For RS256 it is an RSA signature: the issuer signs with a private key and anyone verifies with the public key. You can explore the raw encoding with our Base64 Decoder and reproduce an HS256 signature byte-for-byte with our HMAC Generator.
Worked examples: token → decoded
Header segment · base64url → JSON
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 → { "alg": "HS256", "typ": "JWT" }
Payload claim · exp as Unix seconds → ISO date
"exp": 2000000000 → 2033-05-18T03:33:20.000Z
Edge case · decode is NOT verify
A decoded payload showing "role": "admin" means nothing on its own — the decoder never checks the signature. An attacker can edit any claim and re-encode it. Trust a claim only after your backend verifies the signature with the correct key.
Edge case · wrong segment count
Paste a token with two parts and you get "A JWT must contain exactly three dot-separated segments". A five-part token is a JWE (encrypted JWT, RFC 7516) and needs a private key to decrypt — this decoder handles three-part JWS only. A stray base64url length also throws "Invalid base64url length".
RFC 7519 registered claims reference
These are the seven standard claims the decoder labels and explains. The three time claims are converted from Unix seconds to ISO timestamps automatically; every other key in your payload is a custom claim.
| Claim | Name | Meaning | Type |
|---|---|---|---|
| iss | Issuer | Principal that issued the token | String/URI |
| sub | Subject | Principal the token is about | String/URI |
| aud | Audience | Intended recipients of the token | String or array |
| exp | Expiration Time | Must not be accepted on/after this time | Unix → ISO |
| nbf | Not Before | Must not be accepted before this time | Unix → ISO |
| iat | Issued At | When the token was issued | Unix → ISO |
| jti | JWT ID | Unique identifier to prevent replay | String |
HS256 vs RS256 and other JWT algorithms
The alg header names the signing algorithm. HS256 is symmetric (one shared secret signs and verifies); RS256 is asymmetric (private key signs, public key verifies) and is preferred when verifiers should not be able to mint tokens.
| Algorithm | Family | Key Type | Typical Use |
|---|---|---|---|
| HS256 | HMAC + SHA-256 | Shared secret (symmetric) | Single-service apps, Supabase, internal systems |
| RS256 | RSA + SHA-256 | Public/private pair | Auth0, AWS Cognito, Firebase, OIDC providers |
| ES256 | ECDSA + P-256 + SHA-256 | Public/private pair | Apple Sign-In, modern OIDC, low-bandwidth contexts |
| EdDSA | Ed25519 / Ed448 | Public/private pair | High-performance systems; smallest signatures |
| none | No signature | N/A | NEVER use in production — historical attack vector |
The status verdict this decoder computes (that most don't)
Beyond pretty-printing JSON, this tool runs the same time logic a verifier does. It compares exp against Math.floor(Date.now() / 1000) and prints a human delta: Valid for 2h more or Expired 5m ago, rounded to s / m / h / d. If nbf is set to a future second, the verdict flips to not-yet-valid and shows the ISO start time. A token with no exp at all is flagged "No expiration claim — treat with caution", because non-expiring tokens are a real liability.
One subtle detail: only the numeric exp, nbf, and iat claims are converted to ISO dates. A non-numeric exp(some buggy issuers emit a string) is shown verbatim and is not treated as an expiry — a quick way to spot a malformed issuer. JWTs also cannot be revoked once issued, so keep exp short (minutes) and rely on server-side refresh tokens.
Runs 100% in your browser
Your token never leaves your device. Decoding happens locally in JavaScript — no part of the header, payload, or signature is uploaded or logged. That makes it safe to inspect production tokens during debugging. I tested this decoder with HS256 and RS256 tokens, expired and active exp values, future nbf claims, tokens with no exp, UTF-8 names in the payload, and malformed two-segment input — each produced the correct verdict or a precise error. Still, never paste a token into a tool you don't trust, and rotate any key exposed in a screenshot or chat.
Related encoding & security tools
Decode the raw header and payload segments
Base64 EncoderEncode text to standard or URL-safe Base64
HMAC GeneratorReproduce the HS256 (HMAC-SHA256) signature
Hash GeneratorSHA-256 — the digest behind HS256/RS256
URL EncoderPercent-encode tokens for query strings
URL ParserPull a token out of an OAuth redirect URL
JSON FormatterPretty-print the decoded payload JSON
Image to Base64Encode an image to a Base64 data URI
Base64 to ImageRender a Base64 string back to an image
All ToolsBrowse the full Toolk hub
Guide: JWT Structure ExplainedHeader, payload & signature in depth
Guide: Hashing vs Encryption vs EncodingWhy Base64 is not security
Last updated: August 23, 2026 · Runs 100% in your browser — no uploads, nothing leaves your device.
Frequently asked questions
Does decoding here verify the signature?
No — deliberately. Verification requires the HS256 shared secret or the RS256 public key, and pasting either into any web page would defeat the point of keeping it in your backend. Treat every claim shown as unverified until your server checks the signature with a vetted library.
Is a JWT payload encrypted?
No. The payload is plain JSON that is merely base64url-encoded — anyone holding the token can read it, which this decoder demonstrates in one paste. The signature provides integrity, not confidentiality, so passwords and secrets never belong inside a token.
How does the expiry check work?
The decoder compares the exp claim to your device clock and reports how long the token remains valid or how long ago it expired. A future nbf flips the status to not-yet-valid, and a missing exp is flagged with an explicit caution rather than assumed safe.
Is it risky to paste a real production token here?
The token stays on your device — decoding runs locally and Toolk’s page analytics do not receive tokens you inspect. The real risk is habit: pasting live credentials into any tool normalizes a practice that will eventually leak them. Prefer expired test tokens where possible.
Which claim should I check first when debugging auth failures?
exp, then iss and aud. An expired token explains most rejections; after that, mismatched issuer or audience values fail validation even when the signature is perfectly valid. For building the signing side of HS256 tokens, Toolk’s HMAC Generator (/tools/hmac-generator) computes matching signatures.
Need a different tool?
Browse all 99 browser-based tools (99 currently marked free), or tell us what useful utility we should build next.