Timestamps
Verify Signature (optional)
JWT (JSON Web Token, RFC 7519) is a compact, URL-safe token made of three Base64URL-encoded parts separated by dots: a header (algorithm), a payload (claims), and a signature. This tool decodes the header and payload so you can inspect the claims — it does not verify the signature.
Quick answer
A JWT decoder reads the header and payload of a JSON Web Token by reversing its Base64URL encoding — no key required. JSON Dev Tools decodes the token entirely in your browser, so your token is never uploaded to a server. It can also optionally verify the signature locally (HMAC, RSA, or ECDSA) if you provide the secret or public key — that verification never leaves your browser either.
Key takeaways
- Decoding ≠ verifying — reading claims alone proves nothing about authenticity; use the optional Verify Signature step for that.
- A JWT is not encrypted — anyone holding it can read the payload.
- A JWT is a credential — never paste a production token into a tool that transmits it.
- Local signature verification — paste a known secret or public key to cryptographically verify the signature, entirely client-side via the Web Crypto API.
- 100% private — this decoder (and verifier) runs client-side; your token never leaves your device.
JWT structure explained
Every JWT has three parts separated by .:
- Header — algorithm (
alg) and token type (typ), e.g.{"alg":"HS256","typ":"JWT"} - Payload — claims: user data, roles, and standard fields like
exp,iat,sub - Signature — cryptographic proof; requires the secret or public key to verify. This tool can perform that verification locally if you provide the key.
Standard JWT claims
| Claim | Name | Type | Meaning |
|---|---|---|---|
sub | Subject | string | The user or entity the token is about |
iss | Issuer | string | Who created and signed the token |
exp | Expiration | Unix timestamp | Token must be rejected after this time |
iat | Issued At | Unix timestamp | When the token was created |
nbf | Not Before | Unix timestamp | Token must not be accepted before this time |
aud | Audience | string / array | Who the token is intended for |
HS256 vs RS256
HS256 uses a shared secret — both issuer and verifier must know the same key, making it unsuitable when you cannot share secrets. RS256 uses a private/public key pair — the issuer signs with a private key and any verifier checks with the public key. RS256 is preferred for third-party APIs and OAuth 2.0, because you can distribute the public key openly without compromising security.
Need to work with the JSON inside a token? Try the JSON Formatter or JSON Validator. Timestamps in exp/iat? Use the Unix Timestamp Converter. Worried about privacy? Read is it safe to decode a JWT online?
Frequently Asked Questions
Does this tool verify JWT signatures?
Yes, optionally. After decoding, you can paste the HMAC secret (for HS256/384/512) or the issuer's public key as a JWK (for RS256/384/512 or ES256/384/512), and the tool verifies the signature locally using the browser's Web Crypto API — nothing is transmitted. This is for inspecting tokens you already control or a key you already trust; it does not replace your server's own authentication checks, and a "valid" result only proves the signature matches the key you supplied, not that the key itself is trustworthy.
Is my JWT sent to a server?
No. Decoding happens entirely in your browser using JavaScript. The JWT is split on dots and each part is Base64URL-decoded locally. Your token never leaves your device.
What is the exp field in a JWT?
exp is the expiration time claim, stored as a Unix timestamp (seconds since January 1 1970 UTC). This tool converts it to a human-readable date so you can instantly see when the token expires and whether it is still valid.
Why does my JWT have 3 parts?
A JWT (RFC 7519) has three Base64URL-encoded parts separated by dots: (1) the header with the algorithm and token type, (2) the payload with claims like sub, iat, exp, and custom data, and (3) the signature that proves the token was issued by a trusted party and has not been tampered with.
What is the difference between HS256 and RS256 in a JWT?
HS256 (HMAC-SHA256) uses a shared secret — both the issuer and verifier use the same key. RS256 (RSA-SHA256) uses a private/public key pair — the issuer signs with the private key and verifiers check with the public key. RS256 is preferred when you cannot share a secret, because the public key can be distributed openly without compromising security.
Is it safe to paste a JWT into an online decoder?
With this tool, yes — decoding is entirely client-side and nothing is transmitted. However, many online JWT tools send your token to a server. If you use a tool that transmits data, avoid pasting production tokens; rotate any token you paste into an untrusted tool.
Which JWT algorithms can this tool verify?
HS256/HS384/HS512 (HMAC with a shared secret), RS256/RS384/RS512 (RSA with a public key), and ES256/ES384/ES512 (ECDSA with a public key). Provide the secret for HS* algorithms, or the public key as a JWK for RS*/ES*. PS256/384/512, EdDSA, and alg:none are not currently supported.
Last updated: July 2026