Paste a JSON Web Token to see its header, payload, and every claim in plain language, with expiry checked against your own clock. Then verify the signature with a secret or public key, without the token ever leaving this tab.
Paste it as it arrived: with or without Bearer, quoted, or wrapped across lines. It is decoded in this tab as you type.
The sample is signed with HS256, valid for one hour from the moment you load it, and its secret is filled into the verifier below.
Each segment is labelled and tinted. Header and payload are base64url JSON; the signature is raw bytes.
A JWT is three base64url segments joined by dots: header, payload, signature. Paste one and each segment is marked here.
Paste a token, or load the sample, and its structure, expiry, and algorithm appear here.
Which algorithm signed the token, and with which key. Decoded from base64url.
The decoded header appears here, with every parameter in it explained.
The claims. Encoded, not encrypted: anyone holding the token can read this.
The decoded payload appears here as formatted JSON, ready to copy.
Registered claims from RFC 7519, common OpenID Connect and OAuth claims, and anything custom. Dates are shown in UTC, in your own time zone, and relative to now.
Each claim in the payload is listed here with what it means, and exp, nbf, and iat are turned into readable dates.
Decoding shows what a token says. Only a signature checked with the right key shows who said it and that nothing was changed. The key stays in this tab.
Decode a signed token above and the matching key field appears here: a secret for HS256, HS384, and HS512, or a public key for RS, PS, ES, and EdDSA.
Anyone can write a token that decodes to any claims they like. Only a signature checked with the issuer's key, followed by exp, nbf, iss, and aud checks, makes a token trustworthy. Never make an access decision from a decoded payload alone.
Open your browser's developer tools (F12, or Cmd+Option+I on a Mac), choose the Network tab, then paste a token and verify it. No request carries it: decoding is plain JavaScript and verification is your browser's Web Crypto API. The site's page-view analytics never include what you type into a field.
A token with five segments is a JWE. Its protected header is readable and shown above, but the claims are encrypted with a key only the recipient holds. No decoder can read them without that key, and this page does not try.
Everything here runs in this tab. The token, the secret, and the public key live only in the page's memory: they are never stored or sent, and they are gone when you clear them or close the page. Input is read up to 100,000 characters and keys up to 50,000. Times are compared with this device's clock with no leeway, so near exp or nbf a few seconds of skew between you and the issuer can change the verdict.
Every JWT segment is base64url. Decode one by hand, or encode a test header or payload, with the URL-safe alphabet switched on.
exp, iat, and nbf are Unix seconds. Turn any timestamp into a date, or a date into the number a token should carry.
HS256 is an HMAC over SHA-256. Compute HMACs and SHA digests of any text to see the primitive underneath the signature.
A compact JWT is header.payload.signature, each part base64url-encoded. The first two are JSON that anyone can decode without a key, which is what this page does as you type. The third is a signature over the first two, and only checking it with the right key tells you the token is genuine and unchanged. Everything runs in this tab: the decoder is plain JavaScript, and verification uses the Web Crypto API built into your browser.
Copy it from an Authorization header, a cookie, a log line, or your identity provider's debugger. A leading Bearer, surrounding quotes, and line breaks are stripped for you, and the three segments are labelled so you can see where the header ends and the payload begins.
Both JSON segments are decoded and formatted. Every registered claim and the common OpenID Connect and OAuth ones are explained in plain words, and exp, nbf, iat, and auth_time are shown in UTC, in your own time zone, and as a live countdown, so an expired token is obvious at a glance.
Decoding proves nothing about who made a token. Paste the HMAC secret for HS256, HS384, or HS512, or the issuer's public key as a PEM block, a JWK, or a whole JWK set for RS, PS, ES, and EdDSA, and Web Crypto checks it in this tab.
exp, nbf, and iat become readable dates and a live countdown, with a clear verdict: not expired, expired, not yet valid, or no expiry at all. A 13-digit timestamp written in milliseconds by mistake is caught and explained, as is an iat set in the future.
iss, sub, aud, exp, nbf, iat, and jti from RFC 7519, plus name, email, azp, nonce, auth_time, scope, client_id, and other common OpenID Connect and OAuth claims, each with what it means and the specification it comes from. Custom claims are labelled as custom rather than guessed at.
alg none, a missing signature, header parameters that point to the token's own keys (jku, x5u, jwk), Base64 padding that strict libraries reject, and HMAC secrets shorter than RFC 7518 allows are all flagged with what to do about them.
HS256, HS384, and HS512 with a shared secret; RS256 to RS512, PS256 to PS512, ES256 to ES512, and EdDSA with Ed25519 using an SPKI PEM, a JWK, or a JWK set where the key is picked by kid. Mismatched key types and algorithms are refused by name.
A wrong number of segments, a character outside the base64url alphabet (with its exact position), text that is not JSON, and a header that is not an object each get their own explanation. A five-segment JWE is recognised as encrypted and its header is still shown.
Decoding is plain JavaScript and verification is your browser's Web Crypto API. There is no upload, no storage, and no request carrying the token, which you can confirm in the Network tab of your browser's developer tools.
A JSON Web Token (RFC 7519) is a compact way to pass claims between two parties: three base64url segments joined by dots. The header names the algorithm, the payload holds the claims (who the token is about, who issued it, who it is for, and when it expires), and the signature lets the receiver check that the first two were produced by someone holding the right key and have not been changed. JWTs are most often used as OAuth access tokens and OpenID Connect ID tokens.
Split it at the dots, base64url-decode the first two segments, and parse each result as JSON. That is all decoding is, which is why it needs no key. Paste a token into the box above and it happens as you type. base64url is ordinary Base64 with hyphen and underscore in place of plus and slash, and with the trailing equals signs removed, so a standard Base64 decoder needs those two characters swapped back first.
Only on a page that decodes it locally. A JWT is a bearer credential: whoever holds an unexpired one can usually use it. This page decodes and verifies in your browser and never sends the token anywhere, and you can check that yourself by opening the Network tab in your browser's developer tools before you paste. Even so, prefer expired or test tokens when you can, and never paste a production signing secret or a private key into any site you cannot inspect.
Yes. A signed JWT is encoded, not encrypted. base64url is a reversible text encoding with no key, so anyone who sees the token can read every claim in it. Never put passwords, API keys, or personal data you would not show to every holder of the token into a JWT payload. If the claims must stay private, the token has to be a JWE, which is encrypted.
They are NumericDates: whole or fractional seconds since 1970-01-01 00:00:00 UTC, not milliseconds. exp is the moment after which the token must be rejected, nbf the moment before which it must be rejected, and iat the moment it was issued. For example, exp 1767225600 is 2026-01-01 00:00:00 UTC. Many verifiers allow a little clock skew, typically between zero and five minutes. A 13-digit value is almost always a millisecond timestamp written by mistake, and this page flags it.
HS256 is HMAC with SHA-256. One shared secret both signs and verifies, so every service that can check a token can also create one. RS256 is an RSA signature with SHA-256. The issuer signs with a private key and anyone verifies with the public key, which providers usually publish as a JWK set. HS256 suits a single system that issues and checks its own tokens; RS256, ES256, or EdDSA suit tokens that cross a trust boundary, such as one identity provider and many APIs.
alg none marks an unsecured JWT: the signature segment is empty, so anyone can write any claims they like. The specification allows such tokens, but a verifier that accepts them, or that lets the token's own header decide which algorithm to use, can be handed a forged token. Configure your JWT library with the exact algorithms you expect and reject everything else, including none.
Recompute or check it over the first two segments exactly as they appear in the token (header, a dot, then payload) using the right key. For HS256 that key is the shared secret; for RS256, PS256, ES256, or EdDSA it is the issuer's public key, usually found at the jwks_uri listed in the provider's /.well-known/openid-configuration document. Paste either into the verifier above. A real verifier then checks exp, nbf, iss, and aud as well, because a valid signature only proves who made the token, not that it is still acceptable.
A classic session cookie holds a random ID that the server looks up in its own store, so signing out or revoking access takes effect immediately. A JWT carries its claims with it, so any service holding the key can check it without a lookup, but it stays valid until exp even after the user signs out unless you add a denylist. Many sites use short-lived JWTs between services and a server-side session for the browser. The two are not exclusive: a JWT can itself be stored in a cookie.
A JSON Web Encryption token (RFC 7516) is encrypted rather than only signed. Its compact form has five segments: protected header, encrypted key, initialization vector, ciphertext, and authentication tag. Only the header is readable; the claims are inside the ciphertext and need the recipient's private key or shared key to decrypt. This page recognises a JWE, shows its header, and says plainly that the claims cannot be read without the key.
Explore the growing collection for calculations, documents, writing, and everyday work.