JWT Decoder
Decode a JWT, check its expiry and verify the signature. Runs in your browser.
About this jwt decoder
This JWT decoder shows what is inside a JSON Web Token: the header, the payload and every claim, with exp, iat and nbf turned into real dates. Add the secret or public key and it also checks the signature, entirely in your browser.
It is built for developers and testers working with OAuth, OpenID Connect and API auth. Paste a token, even with its Bearer prefix, and you see right away who issued it, who it is for, and whether it has expired. The three parts of the token are colored so you can see where each one starts. Until a signature is checked, the page says "Decoded, NOT verified", because anyone can write a payload.
A JWT is a live credential. Pasting one into a site that sends it to a server is a real risk. Here, decoding and verification run on your device with the browser's WebCrypto API, and nothing is uploaded or logged.
Features
Header, payload and claims
Both JSON parts are pretty-printed with copy buttons. A claims table explains each registered claim, such as iss, sub, aud and jti, plus common OpenID Connect ones like email and auth_time.
Readable time claims
exp, nbf, iat and auth_time appear as your local time, as UTC and as relative time ("in 42 minutes", "3 days ago"). A live status shows Not expired, Expired or Not valid yet, updated every second.
Signature check for every common algorithm
HS256, HS384, HS512 with a shared secret. RS256 to RS512, PS256 to PS512, ES256, ES384, ES512 and EdDSA (Ed25519) with a public key, where your browser supports it.
Paste keys the way you have them
PEM public keys, PKCS#1 RSA PUBLIC KEY blocks, X.509 certificates, a single JWK, or a whole JWKS from a /.well-known/jwks.json file. With a JWKS, the key is chosen by the token's kid.
Clear warnings
Flags alg none, a missing exp, an iat in the future, an exp that looks like milliseconds, short HMAC secrets, encrypted (JWE) tokens and private keys pasted by mistake.
Forgiving input
Bearer prefixes, surrounding quotes, line breaks and standard Base64 padding are cleaned up. Each part reports its own decoding error, so one bad character does not hide the rest.
How to use the jwt decoder
- 1Paste the token. A Bearer prefix is removed for you.
- 2Read the header, payload and claims, with exp and iat as real dates.
- 3Add the secret or public key to verify the signature.
When to use it
Debugging a 401 Unauthorized
Check whether the token expired, whether aud matches your API, and whether iss is the issuer your server expects.
Confirming a key rotation
Paste the provider's JWKS and see whether the kid in a fresh token matches a published key and verifies.
Checking an ID token after login
Read the email, name, nonce and auth_time claims your app received from the identity provider.
Testing your own token issuer
Make sure your service signs with the algorithm you intended, sets exp, and uses a strong secret. The HMAC generator helps when you want to recompute an HS256 signature by hand.
What is a JWT made of?
A JSON Web Token (RFC 7519) is three Base64url strings joined by dots: header.payload.signature. The header names the algorithm (alg) and often a key ID (kid). The payload holds the claims. The signature is computed over the first two parts with a secret or a private key, as defined in RFC 7515 (JWS).
Base64url is an encoding, not encryption. Swap - for + and _ for /, and any Base64 decoder can read the header and payload. So never put passwords or other secrets in a JWT payload. Tokens with five parts are a different format, JWE (RFC 7516), where the payload is encrypted.
What is the difference between decoding and verifying a JWT?
Decoding just reads the JSON. It proves nothing, because anyone can create a token with any claims they like. Verifying recomputes the signature with the right key and compares it. Only a verified token tells you the claims came from the issuer and were not changed.
HS algorithms use one shared secret for signing and checking. RS, PS, ES and EdDSA use a key pair: the issuer signs with a private key and anyone can verify with the public key, which is why providers publish a JWKS. A real API must also check exp, nbf, iss and aud, and must accept only the algorithms it expects. Libraries that trusted the header's alg value, including alg none, were a well-known source of JWT vulnerabilities in 2015.
What do exp, iat and nbf mean?
They are NumericDate values: whole seconds since 1970-01-01 00:00:00 UTC, the same format as a Unix timestamp. exp is when the token stops being valid. nbf (not before) is when it starts. iat (issued at) is when it was created. A value of 1793361600 means 30 October 2026, 12:00 UTC. You can check any of them with the Unix timestamp converter.
Servers usually allow a small clock skew, often 30 to 60 seconds, so a token can still work just after its exp. Access tokens commonly live 5 to 60 minutes. Refresh tokens last much longer and are often opaque strings rather than JWTs.
Why use Mavros
| Mavros | Typical upload sites | |
|---|---|---|
| Where the token goes | Stays in your browser | Often sent to a server or analytics script |
| Verification | HS, RS, PS, ES and EdDSA via WebCrypto | HS256 only, or none |
| Key formats | PEM, PKCS#1, X.509 certificate, JWK and JWKS by kid | One PEM format |
| Time claims | Local, UTC and relative time with a live status | Raw numbers |
| Status wording | "Decoded, NOT verified" until a key proves it | A green check for any well-formed token |
| Warnings | alg none, missing exp, ms timestamps, short secrets, JWE | Rarely shown |
Tips
- If an HS256 token will not verify, try the Secret is Base64 encoded option. Some providers show the secret in Base64.
- RFC 7518 asks for an HMAC key at least as long as the hash: 32 bytes for HS256. Shorter secrets work but are easier to brute-force offline.
- For RS256 tokens from an identity provider, copy the JSON from its jwks_uri and paste the whole thing. The right key is picked by kid.
- Copy the payload into the JSON formatter when you want to sort its keys or compare two tokens.
- Do not paste production refresh tokens into any website, including this one, unless you control the page. Here, nothing leaves your browser.
Questions
Can a JWT be decoded without the secret?
Yes. The header and payload are only Base64url encoded, so anyone can read them. The secret or public key is needed to verify the signature, not to read the contents.
Is it safe to paste my JWT here?
This page decodes and verifies the token on your device and sends nothing to a server. Still, treat tokens like passwords: prefer test tokens, and avoid pasting live production tokens into tools you do not trust.
How do I check if a JWT is expired?
Look at the exp claim. This tool shows it as a date with a live Expired or Not expired status. exp is in seconds since 1970 in UTC, and servers often allow up to a minute of clock skew.
Why does it say "Invalid signature"?
The key does not match the one that signed the token, or the token was changed. For HS tokens, check whether the secret is Base64 encoded. For RS or ES tokens, check that you pasted the issuer's current public key.
Which algorithms can it verify?
HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 and EdDSA with Ed25519. EdDSA needs a recent browser with Ed25519 support in WebCrypto.
What key formats can I paste?
A PEM public key (BEGIN PUBLIC KEY), an RSA PUBLIC KEY block, an X.509 certificate, a JWK, or a JWKS with several keys. With a JWKS, the key whose kid matches the token header is used.
Is a JWT encrypted?
Usually not. A normal JWT (JWS) is signed, which protects it from changes but not from reading. Encrypted tokens use JWE and have five parts instead of three. This tool can read a JWE header but not decrypt it.
Can it create or sign tokens?
No. Signing needs a private key or secret, and this tool is built only to inspect and verify. Use your auth library or identity provider to issue tokens.