Free JWT Decoder
Paste a JWT and instantly see the decoded header and payload as formatted JSON, with human-readable timestamps for iat, exp, and nbf claims. Expiry status is shown at a glance — valid, expired, or not-yet-valid. The raw Base64URL-encoded signature is shown alongside its algorithm. No token is sent to any server.
Paste a JWT above to decode it.
Decoded 100% in your browser using Base64URL — your token is never sent to any server.
Frequently Asked Questions
What is a JWT?+
A JSON Web Token (JWT) is a compact, URL-safe way to represent claims between two parties. It consists of three Base64URL-encoded parts separated by dots: a header (algorithm and token type), a payload (the claims — user data, expiry, etc.), and a cryptographic signature. JWTs are widely used for authentication and authorization in web APIs.
Does this tool verify the JWT signature?+
No — and that's intentional for a browser-only tool. Verifying a JWT signature requires the secret key (for HMAC algorithms like HS256) or the public key (for RSA/ECDSA algorithms like RS256). This tool decodes and displays the header and payload so you can inspect the claims. For signature verification, use your server-side JWT library.
What do the standard JWT claims mean?+
iss (issuer) — who created the token. sub (subject) — who the token is about, 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) — Unix timestamp before which the token is invalid. iat (issued at) — Unix timestamp when the token was issued. jti (JWT ID) — a unique identifier for the token.
Is it safe to paste my JWT here?+
This tool runs entirely in your browser — your token is never sent to any server or third party. However, as a general security practice, avoid pasting production JWTs (especially long-lived tokens with sensitive claims) into any tool. Use short-lived test tokens for debugging.
What is the difference between HS256, RS256, and ES256?+
HS256 (HMAC-SHA256) — symmetric algorithm. Both the issuer and verifier share the same secret key. RS256 (RSA-SHA256) — asymmetric algorithm. The issuer signs with a private key; verifiers use the corresponding public key. ES256 (ECDSA-SHA256) — also asymmetric but uses elliptic curve cryptography for smaller signatures with equivalent security to RS256.
What does "token expired" mean?+
The exp (expiration) claim is a Unix timestamp. When the current time passes that timestamp, the token is considered expired. Most JWT libraries will reject expired tokens automatically. This tool shows you exactly when the token expired so you can understand why an authentication request is failing.
You might also like
JSON Web Tokens — How They Work
A JSON Web Token (JWT) is a compact, URL-safe method for representing claims between two parties. Defined in RFC 7519, JWTs are the dominant token format for stateless API authentication. A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. Because the header and payload are only Base64URL-encoded (not encrypted), they can be decoded by anyone who holds the token — which is why you should never store sensitive data like passwords or credit card numbers in a JWT payload.
The Header
The header is a JSON object that describes the cryptographic algorithm used to sign the token (alg) and the token type (typ, almost always JWT). Common algorithms: HS256 (HMAC-SHA256, symmetric secret), RS256 (RSA-SHA256, asymmetric key pair), ES256 (ECDSA-SHA256, elliptic curve). If a kid (key ID) claim is present, it tells the verifier which key from a JWKS (JSON Web Key Set) to use for verification.
The Payload and Standard Claims
The payload contains the claims — statements about an entity and additional metadata. Standard registered claims include sub (subject, typically a user ID), iss (issuer), aud (audience), exp (expiration Unix timestamp), nbf (not-before Unix timestamp), iat (issued-at Unix timestamp), and jti (a unique token ID for preventing replay attacks). Private claims are any application-specific fields you add — roles, permissions, display names, etc.
Signature and Verification
The signature is computed over base64url(header) + "." + base64url(payload) using the algorithm specified in the header. For HS256, both the signing and verification use the same secret key. For RS256 and ES256, the server signs with a private key and clients verify with the corresponding public key — which can be published via a JWKS endpoint without exposing the signing secret. This tool shows the raw Base64URL-encoded signature but does not verify it, since verification requires the secret or public key.
Token Expiry and the Clock Skew Problem
The exp claim is a Unix epoch timestamp (seconds since 1 January 1970 UTC). When a server validates a token, it compares the current server time against exp. If the clocks between the issuing server and the verifying server are slightly out of sync, a valid token might appear expired. This is called clock skew. Most JWT libraries allow configuring a small leeway (typically 60 seconds) to tolerate minor clock differences.
JWTs vs. Opaque Tokens
An opaque token is a random string (like a session cookie value) that has no intrinsic meaning — the server must look it up in a database to determine its validity and associated claims. A JWT is self-contained: the claims are encoded in the token itself. This makes JWTs ideal for stateless, horizontally scalable systems where you don't want a shared session store. The trade-off: you can't "revoke" a JWT before it expires without maintaining a deny-list, which reintroduces server-side state.