Is my token or secret sent to a server?

No. Decoding and signature verification run entirely in your browser using the Web Crypto API. Your JWT, your HMAC secret and your keys never leave your device, which is essential because a JWT often carries live credentials.

Which signature algorithms can it verify?

HMAC (HS256/384/512) with a shared secret, and the asymmetric families RS256/384/512, PS256/384/512 and ES256/384/512 with a public key supplied as PEM (SPKI) or JWK.

Does decoding a JWT prove it is valid?

No. Anyone can read the header and payload because they are only Base64url-encoded, not encrypted. A token is only trustworthy once its signature verifies against the correct key, which is why this tool separates decoding from verification.

Can it tell me if a token is expired?

Yes. It converts the iat, nbf and exp claims to readable UTC timestamps and flags whether the token is expired, not yet valid, or how long it remains valid.

JWT Decoder & Verifier (HS/RS/ES/PS) — Local & Private

On this page

How to use it
Decode vs verify
Supported algorithms
Reading claims & expiry
Why local matters
FAQ

How to decode and verify a JWT

A JSON Web Token packs three Base64url segments — header, payload and signature — separated by dots. Paste one into the left pane and it is decoded instantly: the header and payload appear as formatted JSON on the right, the algorithm is shown as a badge, and the registered claims are laid out in a readable table. To check authenticity, provide the key in the box below and press Verify signature. Everything happens in your browser; the token and key never travel anywhere.

Decoding is not the same as verifying

This is the single most important thing to understand about JWTs, and many tools blur it. The header and payload are merely encoded, not encrypted — anyone who holds the token can read them. Decoding therefore proves nothing about trust; a token could be expired, forged, or signed with the wrong key and still decode perfectly. Only the signature establishes that the token was issued by a party holding the secret or private key and has not been altered since. That is why this tool keeps the two steps visibly separate: after decoding it shows "signature not verified" until you supply a key and the cryptographic check passes.

Supported algorithms and keys

Verification uses the browser's Web Crypto implementation, so it is fast and trustworthy and needs no external library. Symmetric HMAC tokens — HS256, HS384, HS512 — are verified by entering the shared secret as plain text. Asymmetric tokens are verified with a public key pasted as PEM (an -----BEGIN PUBLIC KEY----- SPKI block) or as a JWK JSON object. The supported asymmetric families are RSA PKCS#1 v1.5 (RS256/384/512), RSA-PSS (PS256/384/512), and ECDSA (ES256/384/512). The tool reads the algorithm from the token header and applies the matching verification parameters automatically.

Reading claims and expiry at a glance

The payload of most tokens contains a handful of registered claims with special meaning. This tool surfaces them in plain language: iat (issued-at), nbf (not-before) and exp (expiry) are converted from raw Unix seconds into readable UTC timestamps, and the expiry is annotated as EXPIRED, not yet valid, or how many minutes of validity remain. It also pulls out iss (issuer), sub (subject) and aud (audience) so you can confirm at a glance who issued the token and for whom. Any custom claims remain visible in the formatted payload above.

Why a local JWT tool is non-negotiable

JWTs are credentials. A bearer token in the wrong hands can impersonate a user; an HMAC secret can mint unlimited valid tokens. Pasting either into a website that processes them server-side, or into an AI chatbot, hands your live authentication material to a third party that may log, cache or train on it. That is among the most dangerous things you can do with a secret, and it is completely avoidable. Every operation here runs as JavaScript in your own tab using Web Crypto — the token, the secret and the keys are never transmitted, and closing the tab discards them. For a class of data this sensitive, "it stays on your device" is not a nicety, it is the requirement.

gitime.dev is built on exactly this principle. Decoding and verifying tokens is deterministic, security-critical work that belongs where the data already lives: your browser. Nothing here phones home.

Decode header, payload and claims with one paste.
Verify HS/RS/PS/ES signatures via Web Crypto.
Keys accepted as HMAC secret, PEM (SPKI) public key, or JWK.
Expiry and timing claims rendered as readable UTC with status flags.
Everything stays on your device — no upload, no logging.

Frequently asked questions

Is my token or secret sent to a server?: No. Decoding and verification run in your browser via Web Crypto. The token, secret and keys never leave your device.
Which algorithms can it verify?: HS256/384/512 with a secret, plus RS, PS and ES 256/384/512 with a PEM or JWK public key.
Does decoding prove a token is valid?: No. Header and payload are only encoded, not encrypted. A token is trustworthy only once its signature verifies.
Can it detect expiry?: Yes. It renders iat, nbf and exp as UTC and flags expired or not-yet-valid tokens.

JWT Decoder & Verifier