Security Tools New Tool

Free Online JWT Decoder, Signature Verifier and Token Builder

Read what is inside a JSON Web Token, check that its signature is genuine, and sign a token of your own for testing. The header and payload are shown as formatted JSON with the times turned into real dates, the signature is checked against a shared secret or an RSA public key, and the issuer and audience can be checked too.

Free Forever Nothing Uploaded Expiry Checked Reads Only

Free Online JWT Decoder, Signature Verifier and Token Builder

Advertisement Slot (Top Banner) Google AdSense Unit • Responsive Banner

JWT Decoder Everything happens in this tab. Nothing you paste is sent anywhere.

Your token

Inside the token

Header

Payload

Time claim	When (UTC)

What for

Buy Us A Coffee

Enjoying WizTools123? Help keep our server infrastructure 100% free and open for everyone.

Buy Us A Coffee

Sponsored Content (Below Tool) Google AdSense Placement

Verifying Here, and What It Costs You

One of the two ways costs you nothing at all.

A JWT has three parts: a header, a payload, and a signature. The first two are only Base64URL encoded JSON, readable by anyone, which is why the decoder needs nothing from you. The signature proves the token was issued by someone holding the key, and checking it means having that key. Which key depends on how the token was signed, and the difference matters more than it looks.

With RS256, RS384 or RS512 you only need the public key, and a public key is not a secret. It is published on purpose, often at a well known URL your own system already fetches. Pasting it here costs you nothing whatsoever, and the answer is a real cryptographic check: either the token was signed by the holder of the matching private key, or it was not.

With HS256 and its relatives, checking means typing the shared secret, so use a test secret rather than the one your production system signs with. Nothing typed here leaves the tab, which you can confirm in the Network tab or by working offline, and that is the only reason this page is willing to accept a secret at all. It still is not a habit worth forming with a live key: a signing secret protects every token your system issues, and the fewer places it has ever been typed, the better.

A valid signature does not mean a token should be accepted. It says the token is authentic and unaltered, nothing more. An expired token, a token for a different audience and a token from an issuer you do not trust can all carry perfectly valid signatures, and real systems reject tokens for those reasons far more often than for a bad signature. That is why the expiry, the issuer and the audience are checked alongside it here, and why the verdict says so when the signature passes and the claims do not.

A payload you can read is a payload anyone can read. Because the first two parts are only encoded, never encrypted, a secret does not belong in a JWT payload. Names, IDs and roles are normal; a password, a card number or an API key are not. The signature stops the payload being changed, and does nothing at all to hide it.

A token with no signature, or with the algorithm set to none, is exactly what an attacker sends. The verdict here says so plainly rather than passing it, because a library that trusts the header to choose the algorithm can be talked into checking nothing at all. Decide the algorithm in your own code and refuse anything else.

The signing side is for tests, and the token it makes is real. It signs HS256, HS384 and HS512 with the secret you type, so anything holding that secret will accept what comes out. That is the point when you need a token to exercise an endpoint, and it is also why the secret you use here should belong to a test system.

Where Your Input Goes

Nowhere. And you can check that yourself.

A real session token can be inspected here because it is decoded in your browser and never sent anywhere. It is all done by your own browser. Press F12, open the Network tab, and use the tool: the page fetches its own code and nothing else. Or load the page, turn off your wifi, and carry on. It still runs, because there was never a server in the middle.

How to Read, Verify or Sign a JWT

Three jobs on one page, and nothing is uploaded.

Paste your JWT The whole thing, header.payload.signature. It is decoded the moment you paste, and reading it needs no key at all.

Read the header, the payload and the times Both parts as formatted JSON, the algorithm named, and the issued, not-before and expiry claims turned into real dates.

Check the signature, if you want to Switch to Verify and give it the shared secret or the RSA public key. The expected issuer and audience can be checked at the same time, because a valid signature on its own is only half the answer.

Or sign a token for a test Switch to Make, write the payload as JSON and sign it with HS256, HS384 or HS512. What comes out is a real token, so use a test secret.

What to Know About JWTs

Including the things this tool cannot do.

With RS256 the verification costs you nothing, because a public key is not a secret. It is published on purpose, and the check is a real one: either the token was signed by the holder of the matching private key or it was not. With HS256 the check needs the shared secret, which is why that side of the page says to use a test secret rather than the one your live system signs with. Nothing typed here leaves the tab either way.

A JWT payload is readable, not secret, so never put anything sensitive in it. The signature stops the payload being altered, but it does nothing to hide it. Names, user IDs and roles belong there; passwords, card numbers and API keys do not. Decoding any token you hold shows everything inside it, which is the fact this tool makes obvious.

The timestamps become real dates and the expiry is judged against your own clock. The iat, nbf and exp claims are seconds since 1970, unreadable at a glance. They are shown here as UTC dates, and the token is marked expired, not-yet-valid or current by comparing them to your machine. If your clock is off, that verdict is off with it.

None of the three parts is encrypted, which is a common misunderstanding about JWTs. A signed JWT, the usual kind, is protected from tampering but is fully readable. There is a separate encrypted form, JWE, which is rarely used. If you are surprised you can read a token's contents, that is the format working as designed, not a leak.

A valid signature is not permission to accept a token, and this page will tell you so. Expiry, issuer and audience are all checked beside the signature, because in real systems a token is refused for one of those far more often than for a bad signature. What the page cannot tell you is whether the key you used is the right key: that it was signed by whoever holds that key is the whole of what a signature proves.

What this page will not do is make an RS256 token. Signing with RSA means pasting a private key, and a private key is the one thing that should never be typed into a browser, test or not. Verification only needs the public half, so that side is offered and the signing side stops at HMAC.

Key Features & Capabilities

What this tool does, and what it deliberately does not.

Header and payload Both shown as formatted JSON, with the algorithm named.

Times as dates Issued, not-before and expiry turned from seconds into readable UTC dates.

Expiry checked Marked expired, not yet valid, or current against your own clock.

Signature checked Against a shared secret or an RSA public key, by the browser own Web Crypto.

Signs test tokens HS256, HS384 or HS512 with your own payload, iat and expiry.

Nothing uploaded A real session token can be inspected here without it leaving the tab.

About the JWT Encoder and Decoder

A JWT turns up whenever you are working with authentication: a session token, an API key in bearer form, a link that logs someone in. It looks like a wall of Base64, and the quickest way to understand a bug is to see what is actually inside it. That is what this does, in your browser, the moment you paste one in.

It shows the header and the payload as readable JSON, names the signing algorithm, and turns the cryptic timestamps into real dates, then tells you whether the token has expired. If you want more than that it will check the signature, against an RSA public key, which is not a secret at all, or against a shared secret, which is. It will also sign an HMAC token with a payload of your own, which is the quickest way to get a token for exercising an endpoint.

The tool doubles as a reminder of two things people get wrong about JWTs: the payload is readable by anyone, so nothing secret belongs in it, and the token is signed but not encrypted, so being able to read it is the format working correctly. Decoding a token you hold shows you exactly what any recipient can see, which is often the point of checking.

Frequently Asked Questions

Signatures, claims, and why nothing secret belongs in a payload.

Yes. For RS256, RS384 and RS512 it needs only the public key, which is published on purpose and costs you nothing to paste. For HS256 and its relatives it needs the shared secret, so use a test secret rather than your live signing key. Nothing typed here leaves the tab, which you can confirm in the Network tab.

No, and that is deliberate. Signing with RSA means pasting a private key, which is the one thing that should never be typed into a browser. The signing side stops at HMAC, and verification is offered for RSA because the public half is all it needs.

The decoding happens entirely in your browser, so the token is not uploaded. That said, a token in your clipboard history or on screen is still a live credential until it expires. Decode it, learn what you need, and treat it as you would any password.

Yes, and so can anyone else. The header and payload are only Base64URL-encoded, not encrypted, so no key is needed to read them. That is why you must never put anything sensitive in a JWT payload; the signature stops it being changed but not being read.

The expiry is judged against your computer's clock. If your clock is wrong, or the token uses a timezone you did not expect, the verdict can look off. The exact expiry time is shown as a UTC date so you can check it against the real time yourself.

No. It is decoded in your browser with no server involved, which is why inspecting a real session token here is reasonable. You can confirm it in the Network tab or by working offline.