toolgarden.xyz
中文

JWT Parser

Free online JWT parser to decode tokens, inspect Header / Payload, and verify HS256 signatures

JWT Token

HS256 Signature Verification

Paste a JWT token and click Decode

About this tool

A JSON Web Token commonly has header, payload, and signature segments separated by dots. The first two are Base64URL encoded and can be decoded to inspect the declared algorithm, issuer, audience, expiry, and application claims. Encoding is not encryption, so the payload must not contain secrets.

This browser tool inspects JWT structure and claims when diagnosing sign-in, API authorization, and expiry problems. Readable content does not make the signature trustworthy. Real authentication requires server-side verification with trusted keys, an allowlisted algorithm, and strict claim checks.

How to use it

  1. Paste the complete token

    Enter the three JWT segments without a `Bearer` prefix, quotes, or surrounding whitespace.

  2. Inspect header and payload

    Check the algorithm, key identifier, and standard claims such as `iss`, `aud`, `exp`, and `nbf`.

  3. Verify on the server

    When trust matters, use a backend JWT library and trusted configuration to validate the signature and claims.

Input and output example

The payload is only Base64URL encoded, not encrypted; anyone holding the token can read everything below.

JWT
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIiwicm9sZSI6ImFkbWluIiwiZXhwIjoxNzY3MjI1NjAwfQ.<signature>
Decoded
// header
{ "alg": "HS256" }

// payload
{ "sub": "1", "role": "admin", "exp": 1767225600 }
exp → 2026-01-01 00:00:00 UTC

Supported range and limits

What it decodes
The header, payload and signature, with time claims in the payload rendered as readable dates
Signature verification
HS256 symmetric verification is supported. Asymmetric algorithms such as RS256 need a public key and are out of scope here
The payload is not encrypted
It is only Base64URL encoded, so anyone holding the token can read it; never put passwords or secrets inside
Key claims
exp expiry, iat issued-at, nbf not-before, iss issuer, aud audience
Decoding is not validation
A successful decode only proves the format is right. Expiry, signature trust and revocation are separate questions
Security note
A production token is a credential. Prefer tokens issued by a test environment when debugging

When you would use it

  • Diagnosing an expired session

    Convert `exp` and `nbf` values to readable time and check for client-server clock skew.

  • Checking authorization configuration

    Compare issuer, audience, algorithm, and key ID to find environment or key-rotation mistakes.

  • Checking which claims a token actually carries

    When a user is "authorised but denied", decode the token to see the roles and scopes that were really issued, which tells you whether the problem is at the issuer or the verifier.

What to know before you start

  • Decoding only reads encoded data. It neither verifies the signature nor proves who issued the token.
  • JWTs can contain user identifiers and privileges. Do not paste a live production token into an untrusted page.
  • Servers should restrict accepted algorithms and validate expiry, issuer, audience, and any claims required by the use case.

Related concepts

Base64URL
A URL-safe Base64 variant that uses `-` and `_` and commonly omits trailing padding.
registered claims
Standard JWT claim names including `iss`, `sub`, `aud`, `exp`, and `nbf`.

Frequently asked questions

Does decoding a JWT upload my token?
No. The header and payload are decoded locally in your browser, so the token is never uploaded and your credentials stay private.
Can it verify the JWT signature?
Yes. You can supply a secret to verify an HS256 signature locally and confirm the token has not been tampered with.
Can I see the token's expiry?
Yes. After decoding you can read standard claims like exp and iat in the payload to tell whether the token has expired.
Does a successful decode mean the token is valid?
No. Decoding only proves the format. Three separate things still need checking: whether exp has passed, whether the signature is trustworthy, and whether the server has revoked it. Fail any one and the token should not be accepted.
Why should sensitive data stay out of the payload?
The payload is Base64URL encoded, not encrypted. Anyone holding the token can read all of it with no key at all. Passwords, national ID numbers and internal identifiers do not belong there.

Related tools