Is this JWT decoder safe to use with real tokens?

Yes. Everything happens in your browser: the token is decoded on your own machine with standard base64url decoding, and the signature is verified locally with the Web Crypto API. Nothing, not the token, not the secret, not the key, is ever sent to a server. Because a JWT is a bearer credential, that browser-only design is the only responsible way to offer this, and it means the tool is safe to use with live production tokens.

Can it verify the signature, or only decode the token?

Both. Decoding reads the header and payload, which anyone can do because they are only encoded, not encrypted. Verifying proves the token is genuine, which needs the key. Paste the shared secret for an HMAC token (HS256, HS384, HS512), or the PEM public key for an RSA or elliptic-curve token (RS256, PS256, ES256 and their variants), and it runs the real cryptographic check and tells you whether the signature is valid.

Why can I read the payload without any key?

Because a JWT payload is not encrypted. The two readable segments are base64url-encoded, which is a reversible transformation with no key involved, chosen so tokens are compact and URL-safe, not to hide anything. Only the signature uses a key, and only to prove authenticity and integrity, not to conceal the contents. The practical rule that follows is simple: never put a secret in a JWT, because everyone who holds the token can read it.

What is the difference between HS256 and RS256?

They are different families of signature algorithm. HS256 is HMAC with SHA-256: it uses one shared secret both to sign and to verify, so anyone who can verify can also sign, which is fine within a single trusted service. RS256 is RSA with SHA-256: it signs with a private key and verifies with the matching public key, so you can hand out the public key to let others verify tokens they cannot forge. To verify here, HS256 needs the secret; RS256 needs the PEM public key.

My token is being rejected but looks fine. What do I check?

Start with the validity banner. The most common causes are an exp in the past, so the token has expired, or an nbf in the future, so it is not valid yet, both of which this tool spells out as real dates. If the times are fine, verify the signature: a mismatch means the wrong key or a tampered token. Also check that the aud claim matches the service rejecting it and that the iss is the issuer you expect, since a strict server checks both.

Should I store JWTs in local storage?

Generally no. A token in local storage is readable by any JavaScript on the page, so a single cross-site scripting flaw can steal it. The safer pattern for a browser app is an httpOnly cookie, which JavaScript cannot read, combined with protection against cross-site request forgery. This is exactly the kind of decision, tokens, sessions, and where they live, that is worth getting right when you build the real system rather than the prototype.

Free Tool

Free JWT Decoder and Verifier, read every claim, then prove the signature

Paste a JSON Web Token and it is decoded instantly in your browser: the header and payload laid out as readable JSON, every registered claim explained in plain language, and each time claim turned into a real date with a live verdict on whether the token is active, expired or not yet valid. Then go one step further than any decode: paste the secret or the PEM public key and it verifies the signature for real with the Web Crypto API. Your token, secret and key never leave the page.

Encoded token

Decoded and verified in your browser with the Web Crypto API. The token never leaves this page.

Paste a token, or load the sample, to decode its header and payload and check whether it is still valid.

A JSON Web Token looks like an opaque string, but two of its three parts are not encrypted at all, only base64url-encoded, so anyone can read them. That is exactly why developers reach for a decoder dozens of times a day: to see why a login failed, why an API returned 401, what scopes a token actually carries, or whether the thing expired an hour ago. The trouble is what you are pasting. A JWT is a bearer credential: whoever holds it can act as the user it represents until it expires. Paste a live token into one of the many decoders that send it to a server, and you have just handed your session, or worse a service account, to a website you know nothing about, which may log it. The second problem is that decoding is only half the question. Reading the claims tells you what a token says about itself, but not whether it is genuine. A token can be decoded perfectly and still be a forgery, because the signature, the one part that proves it was issued by who it claims and has not been altered, is the part almost no online decoder actually checks. This tool closes both gaps. It decodes everything in your browser so nothing is transmitted, and it verifies the signature with real cryptography, so you can answer not just what the token says but whether you should believe it.

The three parts, and which ones anyone can read

A JWT is three base64url segments joined by dots: header, payload, signature. The header names the algorithm and token type. The payload carries the claims, the statements the token makes: who it is about, who issued it, who it is for, and when it expires. Neither of those first two parts is encrypted. Base64url is an encoding, not a cipher, so decoding them takes no key and reveals everything, which is why you should never put a secret in a JWT payload. The signature is the only part that does real work: it is computed over the header and payload with a key, so any change to either invalidates it. That structure has a direct consequence for how you should treat a token. Because the payload is readable by anyone, a JWT is not a place to hide data. And because only the signature proves authenticity, decoding a token tells you what it claims but never, on its own, whether that claim is true. This tool shows all three parts, colour-coded the way developers recognise, and is honest about which ones are merely encoded and which one has to be verified.

Claims in plain language, and expiry you can actually see

The registered claims are terse three-letter keys for a reason, they travel in every request, but that terseness is where mistakes hide. iss, sub, aud, exp, nbf, iat, jti: each has a precise meaning and a precise failure mode if you ignore it. This tool prints every registered claim it finds with a one-line explanation of what it is and why it matters, so you are not translating an RFC in your head. The three time claims get special treatment, because they are the ones that break in production. exp, nbf and iat are Unix timestamps, seconds since 1970, which are unreadable at a glance and the source of endless confusion between seconds and milliseconds. The tool renders each as a real UTC date and a relative phrase, in two hours, three days ago, and rolls them into a single verdict at the top: active, expired, or not yet valid. That one line answers the question you opened the decoder to ask, without you doing arithmetic on an epoch timestamp.

Verify the signature, do not just trust it

This is the part that makes it a verifier and not just a viewer. Anyone can craft a token that decodes cleanly and claims to be an admin; what stops that token from working is the signature, and checking a signature needs the key and real cryptography. This tool does it in the browser with the Web Crypto API, the same primitives the platform itself uses. For an HMAC token (HS256, HS384, HS512) you paste the shared secret; for an RSA or elliptic-curve token (RS, PS, ES families) you paste the PEM public key, and it tells you plainly whether the signature holds. A valid result means the token was signed with that key and has not been altered since. An invalid result means either the key is wrong or the token was tampered with. It also flags the one algorithm you must never accept: alg none, an unsigned token that some libraries have historically been tricked into trusting. Being able to prove a signature, right next to the decoded claims, is the difference between reading a token and actually trusting it.

How to use it

1
Paste the token
Drop the JWT into the input, with or without a Bearer prefix, or load the sample to see how it works. It is decoded the instant it is valid, entirely in your browser, so even a live production token stays on your machine and is never uploaded.
2
Read the header and payload
See the header and payload as formatted JSON, with each registered claim explained beneath a claims table. The expiry, not-before and issued-at times are shown as real dates with a relative phrase, so you can tell at a glance whether the token is still good.
3
Check the validity verdict
The banner at the top gives the single answer most people came for: active, expired, or not yet valid. If a token that should work is being rejected, this is usually where you find out it lapsed or has a not-before time in the future.
4
Verify the signature
For an HMAC token, paste the shared secret. For an RSA or EC token, paste the PEM public key. The tool runs the real cryptographic check with the Web Crypto API and tells you whether the signature is valid. Copying a decoded segment asks you to sign in with a free account; decoding and verifying never do.

Common mistakes

Pasting a live token into a server-side decoder

Most online JWT decoders send your token to their server to decode it. A JWT is a bearer credential, so that is the same as pasting a password: whoever runs the site can use it until it expires. Only ever decode tokens in a tool that works entirely in the browser, which is exactly why this one does and says so.

Treating the payload as private

The payload is base64url-encoded, not encrypted, so anyone who has the token can read every claim in it without any key. Never put anything secret, a password, an API key, personal data you would not expose, in a JWT payload. If it is in the token, treat it as public.

Decoding a token and assuming it is genuine

A token can decode perfectly and still be forged, because decoding never touches the signature. The claims only mean something once the signature is verified against the right key. Use the verify step before you trust what a token says, especially if you are debugging an authorization decision.

Accepting the alg none algorithm

A token with alg set to none carries no signature at all. Several JWT libraries have historically been fooled into accepting these as valid, letting an attacker forge any token they like. Your verification must reject alg none outright; this tool flags it rather than pretending there is a signature to check.

Questions

Is this JWT decoder safe to use with real tokens?: Yes. Everything happens in your browser: the token is decoded on your own machine with standard base64url decoding, and the signature is verified locally with the Web Crypto API. Nothing, not the token, not the secret, not the key, is ever sent to a server. Because a JWT is a bearer credential, that browser-only design is the only responsible way to offer this, and it means the tool is safe to use with live production tokens.
Can it verify the signature, or only decode the token?: Both. Decoding reads the header and payload, which anyone can do because they are only encoded, not encrypted. Verifying proves the token is genuine, which needs the key. Paste the shared secret for an HMAC token (HS256, HS384, HS512), or the PEM public key for an RSA or elliptic-curve token (RS256, PS256, ES256 and their variants), and it runs the real cryptographic check and tells you whether the signature is valid.
Why can I read the payload without any key?: Because a JWT payload is not encrypted. The two readable segments are base64url-encoded, which is a reversible transformation with no key involved, chosen so tokens are compact and URL-safe, not to hide anything. Only the signature uses a key, and only to prove authenticity and integrity, not to conceal the contents. The practical rule that follows is simple: never put a secret in a JWT, because everyone who holds the token can read it.
What is the difference between HS256 and RS256?: They are different families of signature algorithm. HS256 is HMAC with SHA-256: it uses one shared secret both to sign and to verify, so anyone who can verify can also sign, which is fine within a single trusted service. RS256 is RSA with SHA-256: it signs with a private key and verifies with the matching public key, so you can hand out the public key to let others verify tokens they cannot forge. To verify here, HS256 needs the secret; RS256 needs the PEM public key.
My token is being rejected but looks fine. What do I check?: Start with the validity banner. The most common causes are an exp in the past, so the token has expired, or an nbf in the future, so it is not valid yet, both of which this tool spells out as real dates. If the times are fine, verify the signature: a mismatch means the wrong key or a tampered token. Also check that the aud claim matches the service rejecting it and that the iss is the issuer you expect, since a strict server checks both.
Should I store JWTs in local storage?: Generally no. A token in local storage is readable by any JavaScript on the page, so a single cross-site scripting flaw can steal it. The safer pattern for a browser app is an httpOnly cookie, which JavaScript cannot read, combined with protection against cross-site request forgery. This is exactly the kind of decision, tokens, sessions, and where they live, that is worth getting right when you build the real system rather than the prototype.

Related tools

Need this done properly, at scale?

The tool handles the one-off. When it's a system you're building, that's the paid version of the job, and we do that too.

API & Integrations