Disclosure: Some tools link to SaaS products we may earn a commission from — at no cost to you. All tools are free and run entirely in your browser. See full disclosure →

JWT Decoder

Paste a JSON Web Token to decode the header, inspect all payload claims, and see expiry timestamps in human-readable format. Runs entirely in your browser — nothing is sent to a server. No signature verification is performed.

Header + Payload Expiry Check Claim Timestamps No Verification Client-Side Only
Paste JWT
🔒 No verification. This tool decodes the header and payload only. It does NOT validate the signature, expiry, issuer, or audience. Decoded data is processed entirely in your browser — nothing is sent to a server.

JWT anatomy: the three parts decoded

A JWT looks opaque until you understand its structure. The dots are delimiters, not noise.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9          ← Header (base64url)
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ  ← Payload (base64url)
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  ← Signature (base64url)

Header — a JSON object describing the token type and algorithm. At minimum:

{ "alg": "HS256", "typ": "JWT" }

Payload — a JSON object containing claims. The JWT spec registers standard claims; applications can add custom claims:

{
  "sub": "1234567890",   // subject (user ID)
  "name": "John Doe",   // custom claim
  "iat": 1516239022,    // issued at (Unix timestamp)
  "exp": 1516325422     // expiry (Unix timestamp)
}

Signature — HMAC-SHA256 of base64url(header) + "." + base64url(payload) using the issuer's secret (for HS256) or signed with the issuer's private key (for RS256/ES256). The signature is what makes the token tamper-evident. Modify one character of the payload and the signature no longer matches.

Base64url differs from standard base64 in two characters: + becomes - and / becomes _. Trailing = padding is omitted. This makes the token safe to embed in URLs and HTTP headers without percent-encoding.

Standard claims and what they mean

iss Issuer Who created the token. Validate this matches your expected issuer to prevent cross-tenant token reuse.
sub Subject Who the token is about. Typically a user ID. This is the primary identity claim your application should use.
aud Audience Who the token is intended for. Validate this matches your service name to prevent tokens issued for Service A being accepted by Service B.
exp Expiration Unix timestamp after which the token must be rejected. Display: this decoder converts to UTC datetime for readability.
nbf Not Before Unix timestamp before which the token must be rejected. Used when you issue a token but want it to activate in the future.
iat Issued At When the token was created. Useful for calculating how old a token is, even if exp is far in the future.
jti JWT ID A unique identifier for this specific token. Used to implement token revocation lists — store issued jti values in a blocklist and reject tokens whose jti is listed.

Decoding vs verifying: a critical distinction

Decoding reads the payload. Verifying proves the payload is authentic. They are not the same operation.

Decoding is trivial — any base64url decoder can do it. Verifying requires the issuer's secret or public key and a library that implements the correct algorithm. A decoded token that has not been verified is not trustworthy. An attacker can craft a valid-looking JWT with any claims they want and decode it successfully.

When is decode-only valid? Debugging. When you want to inspect what claims a token contains without needing to trust it — reading the sub for a log entry, checking the exp to see why a session is expiring, understanding what your auth provider is putting in the payload.

When is verification mandatory? Any time your application makes an authorization decision based on token claims. In production code, always use a battle-tested JWT library (jsonwebtoken for Node, PyJWT for Python, java-jwt for Java) and explicitly specify the expected algorithm. Never trust the alg claim from the token itself.

HS256 vs RS256 vs ES256 — choosing a signing algorithm

HS256 (HMAC-SHA256) — symmetric: one shared secret signs and verifies. Fast, simple, suitable for internal microservices where both issuer and verifier are controlled by you. The major risk: any service with the secret can issue tokens. If one service is compromised, all services accepting that secret are exposed.

RS256 (RSA-SHA256) — asymmetric: private key signs, public key verifies. The auth server holds the private key; all other services hold only the public key. A compromised API service cannot forge tokens. The public key is distributable — publish it at a JWKS endpoint (/.well-known/jwks.json) and other services can fetch it. The tradeoff: RSA operations are slower and the key is larger.

ES256 (ECDSA-SHA256) — asymmetric like RS256 but using elliptic curve cryptography. Same security properties as RS256 with significantly smaller keys and faster operations. The recommended choice for new systems. ES256 private keys are 32 bytes; RS256 private keys are typically 2048 bits (256 bytes). Supported by all modern JWT libraries.

JWT security pitfalls that appear in real CVEs

The alg:none attack (CVE-2015-9235 and similar) — described above. Fix: hardcode the expected algorithm in your verification call. Never read it from the token. Most libraries have a algorithms parameter for this purpose.

The RS256-to-HS256 confusion attack — if a library verifies using the algorithm from the token header, an attacker can switch the algorithm from RS256 to HS256 and sign the token with the server's public key (which is, by definition, public knowledge). The library then verifies an HMAC-SHA256 signature using the public key as the HMAC secret — and accepts it. Fix: same as above — specify the algorithm explicitly.

Missing exp validation — common in quick implementations. A token with a past exp is technically still cryptographically valid. If your library verifies the signature but does not check exp, expired tokens continue to work. Most production libraries check exp by default — confirm in your library's documentation.

No audience validation — a token issued for your internal API is valid for your payment service if both use the same signing key and neither validates aud. Set and validate the audience claim, especially in multi-service architectures.

Catch JWT errors in production before users do

Expired token errors, invalid signature exceptions, and missing claim panics show up in Sentry with full stack traces, user context, and request metadata. Configure Sentry's token scrubbing to redact JWTs from error payloads before they hit the dashboard.

Try Sentry free →

FAQ

Is it safe to paste a JWT into this tool? +
This tool processes everything in your browser — nothing is sent to a server. The JavaScript runs locally via your browser engine. That said, treat JWTs as sensitive credentials: they carry authentication claims and should not be pasted into any online tool you do not trust. For sensitive production tokens, prefer a local decoder: 'echo YOUR_JWT | cut -d. -f2 | base64 -d | jq' in a terminal achieves the same result without touching the browser at all.
What is a JWT and what are the three parts? +
A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519. It has three base64url-encoded parts separated by dots: (1) Header — contains the token type ('JWT') and the signing algorithm (e.g. HS256, RS256, ES256). (2) Payload — contains claims: statements about the subject (typically a user ID), plus standard claims like 'iss' (issuer), 'exp' (expiry), 'iat' (issued-at), and 'sub' (subject). (3) Signature — created by signing the encoded header + '.' + encoded payload with the issuer's secret or private key.
Does this tool verify the JWT signature? +
No — and this is intentional. Signature verification requires the issuer's secret (for HMAC algorithms like HS256) or the issuer's public key (for RSA/ECDSA algorithms like RS256, ES256). This tool does not and cannot access those keys. The tool decodes — it reads the base64url-encoded header and payload and displays them as JSON. Decoding is possible without any key. Verification is not. Never trust a JWT's claims solely because you can decode them — a tampered payload can be re-encoded. Only the verified signature proves the token was issued by the expected party.
What standard JWT claims should I look for? +
The registered claim names (RFC 7519 §4.1) are: 'iss' (issuer — who created the token), 'sub' (subject — who the token refers to, typically a user ID), 'aud' (audience — who the token is intended for), 'exp' (expiration time — Unix timestamp after which the token is invalid), 'nbf' (not before — token is invalid before this Unix timestamp), 'iat' (issued at — when the token was created), 'jti' (JWT ID — unique identifier to prevent replay attacks). This decoder highlights exp, iat, and nbf with human-readable timestamps.
What is the alg:none vulnerability? +
The JWT specification allows alg:'none' — a token with no signature at all. Early JWT libraries that trusted the algorithm field from the token itself (rather than enforcing a fixed expected algorithm on the server) could be exploited: an attacker decodes a real token, modifies the payload, re-encodes with alg:'none' and no signature, and if the server accepts it, gains unauthorized access. Modern libraries default to rejecting alg:none. Always configure your JWT validation library to explicitly specify the expected algorithm(s) — never trust what the token claims its algorithm is.
What is the difference between JWS, JWE, and JWT? +
JWT (JSON Web Token) is the overarching format. JWS (JSON Web Signature) is the most common form: a JWT whose payload is signed but not encrypted — this is what this decoder handles. JWE (JSON Web Encryption) is a JWT whose payload is encrypted; you can decode the header (which describes the encryption algorithm) but the payload is ciphertext until decrypted with the recipient's private key. If you paste a JWE into this tool, the payload tab will show garbled content — that is expected.
Checkers & Parsers
Regex Tester Cron Parser Color Contrast Checker
💡
Need AI tools for your development workflow?

Explore our reviews of the best AI coding assistants, documentation generators, and developer productivity tools — ranked by real-world usefulness.

Browse AI Tools for Developers →
The DevTools Team
Infinfy Engineering
We build free developer utilities that we actually use ourselves. No accounts, no tracking, no backend — just fast, accurate, in-browser tools. Part of Infinfy Solutions.