JWT Decoder & Validator
Decode JWT headers and claims, inspect token expiration, and verify supported JWT signatures directly in your browser.
Built and maintained by the Drasken Labs engineering team · Updated
Token processing happens in your browser.
Decoding, claim checks and signature verification run on your device. Tokens, secrets and keys are not uploaded, stored or sent to analytics. Decoding a JWT does not verify its authenticity.
- Free
- No signup required
- Browser-based
- Privacy-focused
JWT Inspection and Validation Tools
Decode JWT
Inspect JWT headers and payload claims, formatted and colour-coded.
Inspect Claims
View common claims such as iss, sub, aud, iat, nbf and exp, with dates in your local time.
Check Expiration
Determine whether a token is expired or not yet valid, with optional clock tolerance.
Verify Signatures
Verify HS, RS, PS and ES signatures using a secret or public key you supply.
Browser-Based
Decoding and verification run in your browser with its Web Crypto API. Nothing is uploaded.
Developer Friendly
Designed for debugging authentication, OAuth and OIDC flows and API integrations.
Supported Algorithms
Signature verification uses the browser’s Web Crypto API. The algorithm is the one you choose — never the one the token claims.
| Algorithm | Signature scheme | Verification material | Status |
|---|---|---|---|
| HS256, HS384, HS512 | HMAC with SHA-2 | Shared secret (plain text or Base64URL) | Supported |
| RS256, RS384, RS512 | RSASSA-PKCS1-v1_5 with SHA-2 | RSA public key — PEM, JWK or JWK Set | Supported |
| PS256, PS384, PS512 | RSASSA-PSS with SHA-2 | RSA public key — PEM, JWK or JWK Set | Supported |
| ES256, ES384, ES512 | ECDSA on P-256, P-384, P-521 | EC public key — PEM, JWK or JWK Set | Supported |
| EdDSA | Ed25519 | — | Decoded, not verified |
none | No signature | — | Never verified — always reported as unsigned |
Algorithm names come from RFC 7518 (JSON Web Algorithms). Encrypted tokens (JWE, five sections) cannot be decoded without the recipient’s private key. Keys that a token names or embeds itself (jku, x5u, jwk, x5c) are never used.
How JWT Validation Works
- 01
Decode the token
Split it into header, payload and signature, and read the Base64URL-encoded JSON. Anyone can do this.
- 02
Validate the claims
Check exp and nbf against the clock, and iss and aud against the values your application expects.
- 03
Verify the signature
Check the signature with the algorithm you expect and the issuer’s secret or public key.
- 04
Decide whether to trust it
Only a token that passes both checks, from an issuer and key you trust, should be accepted.
JWT Example
A synthetic token — no real issuer, user or credential — and what it decodes to. The tool’s Load Example button uses the same token and its demo secret.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJFeGFtcGxlIFVzZXIiLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJpYXQiOjE3OTAwMDAwMDAsImV4cCI6NDEwMjQ0NDgwMH0.X39p6YbFdYHvdpZ3JYFgUi6B14faiTvP4r1cGPGd9hk
- ■ Header
- ■ Payload
- ■ Signature
Header
{
"alg": "HS256",
"typ": "JWT"
}Payload
{
"sub": "user_123",
"name": "Example User",
"iss": "https://auth.example.com",
"aud": "api.example.com",
"iat": 1790000000,
"exp": 4102444800
}What Is a JWT?
A JSON Web Token (JWT, RFC 7519) is a compact string that carries a set of claims — who the token is about, who issued it, who it is for and when it expires. APIs use JWTs as bearer tokens: the client sends one with each request, and the server decides from the token alone whether to allow it.
JWTs are the standard format for OpenID Connect ID tokens and a common format for OAuth 2.0 access tokens, and they are widely used for session and service-to-service authentication.
What Does a JWT Look Like?
A signed JWT is a long string of three Base64URL-encoded sections separated by dots: HEADER.PAYLOAD.SIGNATURE. It usually starts with eyJ, the encoding of {". The header and payload are JSON you can decode and read; the signature is binary data that proves the first two sections have not been changed.
- Header
- Algorithm and token metadata — the signing algorithm (
alg), the type (typ) and often a key ID (kid). - Payload
- The claims: registered ones such as
iss,sub,audandexp, plus any the issuer adds. - Signature
- A cryptographic signature over the first two sections, made with the issuer’s secret or private key.
The header and payload are encoded, not encrypted: anyone who has the token can read them. The signature protects them from being changed, not from being read.
How JWT Authentication Works
- The user signs in with an authentication server (an identity provider).
- The server issues a JWT, signed with its secret or private key.
- The client stores the token and sends it with API requests, usually as
Authorization: Bearer …. - The API verifies the signature with the expected algorithm and key, then validates the claims — expiry, issuer and audience — before trusting anything in the payload.
What Does JWT Validation Mean?
Validating a JWT means deciding whether to trust it, which takes three separate checks: its structure is well formed, its claims (expiry, issuer, audience) match your rules, and its signature verifies with the algorithm and key you expect. Decoding alone is none of these.
- Structure: three Base64URL sections, a JSON header with an algorithm, and a JSON claims set.
- Claims: the token has not expired (
exp), is already valid (nbf), and was issued by (iss) and for (aud) the parties you expect. - Signature: the signature verifies with the algorithm your application expects and a key you trust.
A successful signature verification only confirms that the signature matches the supplied verification material and algorithm. Trust decisions also depend on factors such as issuer, audience, key provenance and application policy.
Is a JWT Encrypted?
Usually not. Almost every JWT is signed, not encrypted: its header and payload are only Base64URL-encoded, so anyone holding the token can read the claims. Signing proves the token has not been changed; only an encrypted token (JWE) hides its contents. Three terms are often confused:
- Encoding (Base64URL) makes the JSON safe to put in a URL or header. It hides nothing.
- Signing (JWS, RFC 7515 — what almost every JWT uses) proves who created the token and that it has not been changed. It does not hide the contents.
- Encryption (JWE, RFC 7516, five sections) hides the contents from anyone without the key.
An ordinary signed JWT provides no confidentiality: never put passwords, secrets or sensitive personal data in its claims.
Decode vs Validate vs Verify a JWT
| Operation | What it does | What it proves |
|---|---|---|
| Decode | Reads the encoded header and payload | Nothing about authenticity — anyone can decode, or forge, a token |
| Validate claims | Checks claims such as expiration, issuer and audience against supplied rules | The token is current and meant for you, if it is genuine |
| Verify signature | Cryptographically checks the signature against verification material | The token was signed with that key and has not been changed |
Decoding alone does not establish authenticity. Accept a token only when its signature verifies with a trusted key and its claims are valid.
Related Developer Tools
Related Engineering Resources
Articles from the Drasken Labs engineering blog on building and securing software.
Building an API or Custom Application?
Drasken Labs designs and builds custom software, SaaS products, web applications and APIs for businesses that need production-ready engineering solutions.
API & System Integrations
Connect applications, CRMs, payment systems, databases and external APIs.
Customer & Vendor Portals
Secure portals, dashboards, documents and self-service workflows.
SaaS Platforms
Multi-user and multi-tenant products with subscriptions, dashboards and administration.
Frequently Asked Questions
How the tool decodes, validates and verifies tokens — and what happens to your data.
Still have a question?
Ask an engineerWhat is a JWT?
A JSON Web Token (RFC 7519) is a compact, URL-safe string that carries claims — statements such as who the user is and when the token expires — between two parties. It is most often used as an access or ID token in OAuth 2.0 and OpenID Connect.
Can I decode a JWT without the secret?
Yes. JWT headers and payloads are normally encoded rather than encrypted, so they can be decoded without the signing secret. The secret or public key is only needed to verify the signature.
Does decoding a JWT mean it is valid?
No. Decoding does not prove authenticity. Anyone can create a token with any claims; only a verified signature from a key you trust, plus valid claims, shows the token is genuine and current.
Can this tool verify a JWT signature?
Yes, for supported algorithms and when the appropriate verification material is supplied: HS256, HS384 and HS512 with the shared secret; RS256, RS384, RS512, PS256, PS384 and PS512 with an RSA public key; and ES256, ES384 and ES512 with an EC public key. Keys can be PEM, a JWK or a JWK Set.
Is JWT validation the same as JWT signature verification?
No. Claim validation and signature verification are separate checks. Claim validation compares exp, nbf, iss and aud with the clock and your expected values; signature verification proves the token was signed with the key you supplied. A token must pass both.
Can I check whether a JWT is expired?
Yes, when the token contains an exp claim. The tool compares exp and nbf with your device’s clock, optionally with a clock tolerance, and shows the dates in your local time zone.
Is my JWT uploaded?
No. Decoding, claim checks and signature verification run in your browser; verification uses the browser’s built-in Web Crypto API. Tokens, secrets and keys are not uploaded, stored or logged. Anonymous usage statistics record only which step was used and its outcome — never the token, its claims, a secret or a key.
Should I paste production tokens into an online JWT tool?
Be cautious. A live access token works as a credential until it expires, and its claims may contain personal data. Prefer test or expired tokens, never paste private keys, and only use tools that process tokens locally — as this one does — when you do need to inspect a real token. Rotate a secret if you suspect it has been exposed.