JWT Decoder, Verifier & Security Analyzer

Decode and audit JWTs instantly in your browser. Inspect claims, detect security risks, flag PII, analyze certificate chains, and get fix recommendations — no server, no upload.

What JWT Decoder, Verifier & Security Analyzer Does

It splits a JWT into its three base64url-encoded segments, decodes the header and payload to readable JSON, verifies the signature against a supplied HMAC secret or asymmetric public key, then produces a structured analysis report covering token identity, claim validation, security warnings ranked by severity, a 0–100 risk score, a privacy score based on detected PII claims, roles and permissions extraction, JWK/JWKS key metadata, and numbered remediation recommendations.

Who Uses This Tool

JWT Decoder, Verifier & Security Analyzer is built for Backend developers, security engineers, API integrators, QA engineers, DevOps engineers, identity platform engineers, penetration testers. Whether you are processing data as part of an automated pipeline or need a quick one-off conversion in your browser, the tool requires no installation and no account — paste your input and get your result in seconds.

Primary Use Case

Verifying a JWT signature against a known secret or public key while simultaneously auditing the token for expired claims, weak algorithms, missing security fields, and embedded PII.

The Problem It Solves

Verifying a JWT signature normally requires a local script, a library, and the correct key material — then you still need to separately check expiry, algorithm safety, claim completeness, and PII exposure across multiple tools. This tool performs the full decode, cryptographic verification, and security audit in one pass inside the browser, with no data sent to a server.

Example

Input
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiZW1haWwiOiJqYW5lQGV4YW1wbGUuY29tIiwicm9sZXMiOlsiYWRtaW4iLCJ1c2VyIl0sImlhdCI6MTcxNjIzOTAyMiwiZXhwIjo0ODU5ODM5MDIyfQ.chjWWBgLHP5cuMsTyqZ_W2jUmHz11omgz2opQzYPgRQ
Secret: supersecret
Output
--- TOKEN IDENTITY -----------------------------------

  Type          JWT
  Fingerprint   4e76a382eae945e1...  (SHA-256)

--- HEADER -------------------------------------------

{
  "alg": "HS256",
  "typ": "JWT"
}

  alg  HS256  /  HMAC-SHA-256 / Symmetric
  typ  JWT  /  Token type

--- PAYLOAD ------------------------------------------

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "email": "jane@example.com",
  "roles": [
    "admin",
    "user"
  ],
  "iat": 1716239022,
  "exp": 4859839022
}

  Registered Claims (RFC 7519)
  sub  1234567890  /  Subject
  iat  Mon, 20 May 2024 21:03:42 UTC  (743d 1h ago)  /  Issued At
  exp  Sun, 02 Jan 2124 03:17:02 UTC  (in 35641d 5h)  /  Expiration Time

  Known Claims
  name   Jane Doe  /  Full name
  email  jane@example.com  /  Email [PII]
  roles  ["admin","user"]  /  Roles
         |- "admin"
         `- "user"

--- SIGNATURE ----------------------------------------

  chjWWBgLHP5cuMsTyqZ_W2jUmHz11omgz2opQzYPgRQ

  43 chars  /  HS256  /  HMAC-SHA-256 / Symmetric

  [PASS]    Signature verified.

--- TOKEN STATS --------------------------------------

  Total length    247 chars
  Header          36    encoded  ->  27 decoded
  Payload         166   encoded  ->  124 decoded
  Signature       43 chars

  Claims          6  (3 RFC 7519/3 known)

  Token age       743d 1h
  Lifetime        36384d 6h
  Elapsed         [░░░░░░░░░░░░░░░░░░░░░░░░] 2  %
  Expires in      35641d 5h

--- CLAIM & HEADER VALIDATION ------------------------

  [PASS]  All standard claims and header fields are well-formed.

--- SECURITY ANALYSIS --------------------------------

  [WARNING]   weak secret (heuristic strength estimate) -- easily brute-forced; use a long random secret

  [WARNING]   lifetime is 36384d 6h -- exceeds 1 year

  [WARNING]   no aud claim -- any recipient can accept this token

  [INFO]      no iss claim

  [INFO]      PII in payload: name, email -- HTTPS only

  [INFO]      no jti claim -- replay protection requires a token ID

--- RISK & PRIVACY -----------------------------------

  Security score  [████████████████░░░░░░░░] 66/100  Fair
  Privacy risk    [██████████░░░░░░░░░░░░░░]  Medium
  PII present     email, name

  Secret length   11 chars
  Charset size    26
  Est. strength   52 bits  (Weak)

--- RECOMMENDATIONS ----------------------------------

  1. Replace the HMAC secret with a cryptographically random value of at least 256 bits (32 bytes). Example (OpenSSL): openssl rand -base64 32

  2. Reduce token lifetime. A lifetime of 36384d 6h greatly extends the exposure window if the token is compromised. Use short-lived access tokens combined with refresh tokens.

  3. Add an aud (audience) claim and validate it on every request. Without aud, a token issued for one service can be replayed against another.

  4. Add a jti (JWT ID) claim and maintain a short-lived server-side blocklist to detect and reject replayed tokens.

  5. PII detected in payload (name, email). Ensure all channels transmitting this token use TLS. Consider moving sensitive attributes to a dedicated userinfo endpoint rather than embedding them in the token.

--- ROLES & PERMISSIONS ------------------------------

  [roles]
    - admin
    - user

--- RAW SEGMENTS -------------------------------------

  Header segment:
    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

  Payload segment:
    eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiZW1haWwiOiJqYW5lQGV4YW1wbGUuY29tIiwicm9sZXMiOlsiYWRtaW4iLCJ1c2VyIl0sImlhdCI6MTcxNjIzOTAyMiwiZXhwIjo0ODU5ODM5MDIyfQ

  Signature segment:
    chjWWBgLHP5cuMsTyqZ_W2jUmHz11omgz2opQzYPgRQ

What to Do With the Output

They use the signature pass/fail result to accept or reject a token in a code review or debugging session, copy security warnings into bug reports or security reviews, act on numbered recommendations to fix token configuration, and confirm claim values before adjusting auth server settings.

Common Mistakes to Avoid

1) Pasting the full Authorization header including the Bearer prefix — the tool expects only the raw dot-separated token string. 2) Providing an HMAC secret that is base64- or hex-encoded rather than the raw UTF-8 string — the tool treats the secret as raw UTF-8; decode it first if your system encodes it. 3) Supplying a certificate PEM (-----BEGIN CERTIFICATE-----) instead of a public key PEM (-----BEGIN PUBLIC KEY-----) or JWK for asymmetric verification — certificate PEM is not supported. 4) Pasting a JWE (five-dot-separated parts) — the tool detects and rejects this immediately, as decryption requires the recipient's private key. 5) Expecting EdDSA (Ed25519) signature verification — the browser WebCrypto API does not expose Ed25519 verify; the tool will warn but cannot verify.

How It Works

The tool splits the token on . and validates exactly three segments, rejecting five-part JWEs. Each segment is base64url-decoded by replacing - with + and _ with /, padding to a multiple of four, then decoded to UTF-8 via TextDecoder with a manual multi-byte fallback. If header.zip is "DEF", the payload is inflated using DecompressionStream("deflate-raw"). Signature verification uses WebCrypto: HMAC secrets are imported as raw keys via crypto.subtle.importKey, asymmetric keys are accepted as SPKI PEM, JWK, or JWKS — with kid-based matching for JWKS. ECDSA signatures are converted from JOSE compact R‖S format to DER before verification. The risk score starts at 100 and deducts for alg:none or missing alg (−40), no exp (−15), expired token (−20), excessive lifetime (−5 to −10), missing iss/aud/jti (−5 each), PII presence (up to −10), jku over HTTP (−15), embedded jwk (−10), and invalid signature (−20). Duplicate JSON keys in both header and payload are detected by character-by-character raw string scanning, bypassing JSON.parse. x5c certificate chains are parsed from DER bytes using an ASN.1 TLV reader and chain signatures verified using WebCrypto. All processing is client-side.

Pro Tip

Paste a JWKS document (e.g. fetched from your identity provider's /.well-known/jwks.json endpoint) directly into the secret field. The tool will display a SUPPLIED KEY ANALYSIS section showing each key's type, size, curve, use, algorithm, and kid, then automatically match the token's kid header to the correct key in the set and attempt verification — letting you audit an entire key rotation without writing any code.

Also Known As

JWT Decoder, Verifier & Security Analyzer is also commonly referred to as JWT verifier online, JSON Web Token verifier, verify JWT signature, JWT debugger, decode JWT online, JWT parser, JWT inspector, JWT claim viewer, JWT security audit tool, JWT expiry checker, JWKS key inspector. All of these terms describe the same conversion — no matter what you call it, this tool handles it.

Frequently Asked Questions

HMAC algorithms HS256, HS384, and HS512 are verified using a raw UTF-8 secret. Asymmetric algorithms RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, and ES512 are verified using an SPKI PEM public key, a JWK, or a JWKS document. EdDSA (Ed25519) is not supported by the browser WebCrypto API and will return an unsupported warning.
Paste the token in the input field, then paste the issuer's public key in SPKI PEM format (-----BEGIN PUBLIC KEY-----) or as a JWK/JWKS JSON object into the secret field and click Full Decode. The tool will import the key via WebCrypto and return a [PASS] or [FAIL] result in the signature section.
No. All decoding, verification, and analysis runs entirely in the browser using native APIs including TextDecoder, crypto.subtle, and DecompressionStream. No token, key, or claim data is transmitted or logged.
The score starts at 100 and deducts points for: alg:none or missing algorithm (−40), no exp claim (−15), expired token (−20), excessive lifetime over one year (−5 to −10), missing iss, aud, or jti (−5 each), PII in payload (up to −10), jku over HTTP (−15), embedded jwk (−10), and a failed signature verification (−20).
Yes. Paste the full JWKS JSON object ({"keys":[...]}) into the secret field. If the token has a kid header, the tool matches it to the corresponding key in the set automatically. If no kid is present, it tries each key in order until one verifies successfully.
The tool scans the raw JSON string character-by-character to detect duplicate top-level keys in both the header and payload without relying on JSON.parse, which silently keeps only the last value. Duplicates are flagged as a critical warning because different parsers may disagree on which value wins, making them a known algorithm-confusion and claim injection vector.