Skip to content

Decode and verify JWTs

Decode a JSON Web Token's header and claims, check its expiry and verify its signature; the token never leaves your browser.

Decoded and verified in this tab — the token and keys are never sent anywhere.

The header, claims and expiry appear here when you paste a token.
Runs in your browser · no uploadHow it works

How to use JWT decoder

  1. 1

    Paste the token

    Paste the JWT from an Authorization header, a cookie or your app’s storage; a leading “Bearer ” is ignored.

  2. 2

    Read the claims

    Check the header and payload tables, the readable exp, iat and nbf times, and the expiry banner.

  3. 3

    Add the key

    Enter the HMAC secret, or paste the public key as PEM, certificate, JWK or JWKS.

  4. 4

    Verify the signature

    Press Verify signature to confirm the token was signed with that key and hasn’t been changed.

Limits and Pro

Free with no sign-up and no limit on the number of tokens; verification supports 13 algorithms (HS, RS, PS and ES at 256, 384 and 512 bits, plus EdDSA).

Pro removes the ads; decoding and verification are the same on every plan. See Pro

About JWT decoder

A JSON Web Token is three Base64URL strings joined by dots: a header naming the signing algorithm, a payload of claims, and a signature. Paste one — with or without the “Bearer ” prefix — and the decoder shows the header and payload as a readable table or pretty-printed JSON, colours the three parts of the token, and explains standard fields such as iss, sub, aud, kid and scope.

Time claims are converted for you: exp, iat, nbf and auth_time appear as a date in your time zone, in UTC and as a relative time (“expires in 2 hours”, “expired 3 days ago”). A banner tells you at a glance whether the token is expired, not valid yet or has no expiry, and warns when exp seems to be in milliseconds instead of seconds.

Decoding proves nothing about who issued a token, so the verifier checks the signature with your browser's built-in WebCrypto. HS256, HS384 and HS512 need the shared secret (plain text or Base64). RS, PS and ES algorithms at 256, 384 and 512 bits, plus EdDSA with Ed25519, need the public key, which you can paste as a PEM public key, an RSA PUBLIC KEY block, an X.509 certificate, a single JWK or a whole JWKS, where the key is picked by the token's kid.

The tool can't decrypt JWE tokens (the five-part kind) and doesn't fetch JWKS URLs; open the issuer's jwks_uri yourself and paste its JSON.

Privacy

Tokens are bearer credentials, so this page treats them that way: decoding and signature checks run in your browser with WebCrypto, and the token, secret and keys are never sent to a server, logged or stored. Closing or reloading the tab clears everything.

Features

Readable times

exp, iat and nbf in your time zone, in UTC and as “in 2 hours” or “3 days ago”.

Real signature checks

HMAC, RSA, RSA-PSS, ECDSA and Ed25519 verified with WebCrypto against your key or JWKS.

Token stays local

Nothing is uploaded, so production tokens can be inspected safely.

JWT decoder: frequently asked questions

Is it safe to paste a production token here?
The token is decoded and verified by JavaScript running in your tab, and no request containing it is made, which you can confirm in your browser's network panel. Still, a valid token works like a password until it expires, so avoid pasting live tokens into any site you don't trust, and prefer expired or test tokens when sharing screenshots.
Why does a decoded token not prove anything?
Anyone can create a header and payload and Base64URL-encode them; decoding just reverses that. Only the signature ties the token to its issuer. Verify it with the issuer's public key or the shared secret before trusting any claim, and check that alg is what your server expects, because accepting “none” or a switched algorithm is a classic vulnerability.
Where do I find the public key to verify an RS256 or ES256 token?
Identity providers publish their keys as a JWK Set. Look up the issuer's /.well-known/openid-configuration, open the jwks_uri it lists, and paste that JSON here; the key whose kid matches the token header is used. You can also paste a PEM public key or the issuer's X.509 certificate.
What do exp, iat and nbf mean?
They are NumericDate claims counted in seconds since 1 January 1970 UTC. exp is when the token stops being valid, iat is when it was issued and nbf is the earliest time it may be accepted. Servers usually allow a minute or two of clock skew. The decoder shows each one as a local date, a UTC timestamp and a relative time.
Why does verification fail with the right HMAC secret?
Common causes are whitespace copied with the secret, a secret that was Base64-encoded when the token was signed, or a token re-encoded by a tool that changed the header or payload bytes. Try the “Secret is Base64-encoded” switch. Any change to the first two parts, even reordered JSON keys, invalidates the signature.

Related tools

All developer tools

Base64 & URL encoder

Encode and decode Base64, URL and HTML entities

Hash generator

MD5, SHA-1, SHA-256, SHA-512 for text and files

JSON formatter & validator

Beautify, minify and validate JSON with error hints

Unix timestamp converter

Epoch time to date and back, in any time zone