Short title

JWT Debugger Tool (Decode & Verify)

Debug JWT tokens online with our JWT debugger tool. Decode header and payload claims, verify HS256, RS256, and ES256 signatures, and inspect expiry locally.

Presets:
Lbl encoded token
Lbl header color(74B)
.
Lbl payload color(248B)
.
Lbl signature color(342B)
PKCS#1 / X.509 SPKI
Lbl clock skew:
60s
Length: 666 charsSegments: 3/3
Lbl header color • Lbl payload color • Lbl signature color
Expiration (exp): 244d ago
Lbl decoded headeralg: RS256
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "auth0-key-2026-prod"
}
Lbl decoded payload6 registered & custom claims
{
  "iss": "https://auth.example.com/",
  "sub": "auth0|64f1a2b3c4d5e6f7",
  "aud": "https://api.example.com/v2/",
  "iat": 1772500000,
  "exp": 1772586400,
  "scope": "read:profile write:reports openid email"
}
iss (Issuer): https://auth.example.com/
sub (Subject): auth0|64f1a2b3c4d5e6f7
aud (Audience): "https://api.example.com/v2/"
iat (Issued At): 245d ago
Status:UNVERIFIED|Time: 0ms
Lbl stat size666 B
Lbl stat algorithmRS256
Lbl stat expiryLbl status expired
Lbl stat audit85/100
Lbl stat verificationLbl signature unchecked
Lbl stat claims6 Claims

Client-Side Processing

High-performance calculation executed entirely in browser memory.

Zero Server Upload Privacy

All payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

ToolsAA•100% Client-Side Private Web Utilities
Technical Reference & Architecture Guide

JWT Debugger Tool (Decode & Verify) Guide

Debug JWT tokens online with our JWT debugger tool. Decode header and payload claims, verify HS256, RS256, and ES256 signatures, and inspect expiry locally.

JWT Debugger Tool (Decode & Verify) Guide — Client-Side In-Memory Architecture & Data Flow
JWT Debugger Tool (Decode & Verify) Guide — Client-Side In-Memory Architecture & Data Flow

Key Parameters & Controls

JOSE Header (Javascript Object Signing and Encryption)JSON Object (RFC 7515 JWS Specification)

Specifies cryptographic algorithm ('alg': HS256, RS256, ES256) and token type ('typ': 'JWT'). Must enforce strict algorithm allowlists on the verifier to block algorithm confusion attacks. Parsed in O(n) linear scan time without regex backtracking.

Default: {"alg":"HS256","typ":"JWT"}
JWT Claims Payload (RFC 7519 Claims Set)JSON Object (RFC 7519 Specification)

Contains identity assertions, entity metadata, and access scopes. Standard registered claims include 'sub' (subject), 'iss' (issuer), 'aud' (audience), 'iat' (issued at), and 'exp' (expiration in POSIX epoch seconds). Local Web Crypto API sandbox decodes claims in O(n) time with zero external network transmission.

Default: {"sub":"user_123","iat":1772500000,"exp":1772503600}
JWS Compact SignatureBase64URL Binary Cryptographic Digest

Cryptographic digest generated by signing 'Base64URL(Header) + "." + Base64URL(Payload)' with the private key or shared secret. Verifies message authenticity and payload integrity using constant-time comparison against timing side-channel attacks.

Default: Base64URL-encoded HMAC or RSA signature
HMAC Shared Secret / Public PEM KeyCryptographic Key Material (SPKI PEM / Raw Secret)

Cryptographic key used to verify the signature. HS256 requires a minimum 256-bit (32-byte) secret to prevent offline dictionary brute-forcing; RS256 requires a 2048-bit or 4096-bit RSA SPKI PEM public key; ES256 requires a P-256 (secp256r1) public key imported via Web Crypto API crypto.subtle.importKey().

Default: your-256-bit-secret
Clock Skew Tolerance (Leeway)Temporal Offset Boundary (Seconds)

Allowable operational time variance (standard interval: 30 to 120 seconds, benchmark: 60 seconds) compensating for Network Time Protocol (NTP) clock drift between the authentication issuer and resource verifiers during 'exp' and 'nbf' claim validation.

Default: 60 seconds

Pro Tips & Best Practices

Never Rely on Client-Side JWT Decoding Alone (Verify Signature on Resource Server)

Decoding a JWT via Base64URL in frontend JavaScript reveals claims for UI personalization (e.g. displaying username), but proves zero authenticity. A malicious actor can tamper with payload claims like 'role: admin' in seconds. Production API gateways and backend servers must mathematically verify the JWS signature using a trusted secret or public key before authorizing requests.

Defending Against the 'alg: none' Cryptographic Bypass Attack (RFC 8725 §3.1)

RFC 7519 permits an 'alg: none' token type for unsecured contexts. Vulnerable verification libraries accept 'alg: none' tokens with an empty signature block, allowing attackers to forge arbitrary claims. Always configure your JWT verification middleware with an explicit algorithm allowlist (e.g. algorithms: ['RS256']), and reject tokens where 'alg' is 'none' or mismatches the expected cipher.

Enforce the 256-Bit Entropy Minimum for HS256 Secrets (RFC 7518 §3.2)

Symmetric HMAC signatures are only as strong as the shared secret. If an HS256 secret is a common word or under 32 bytes (256 bits), offline brute-force cracking tools like hashcat can recover the secret in seconds from intercepted tokens. Use cryptographically random 256-bit keys generated via 'crypto.getRandomValues(new Uint8Array(32))' or CSPRNG.

Mitigate Key Confusion Attacks Between Symmetric and Asymmetric Ciphers (RFC 8725 §3.2)

In an algorithm confusion attack, an attacker alters an RS256 token header to 'HS256' and signs it using the server's public RSA key as the HMAC shared secret. If the backend verification library dynamically evaluates algorithms without strict key-type checking, it validates the forged token. Defend against this by pinning expected algorithms per endpoint and strictly segregating HMAC and RSA key stores.

JWT Payload Is Encoded, NOT Encrypted (Never Store Passwords or PII)

A standard JWT is a signed JWS (JSON Web Signature), not an encrypted JWE (JSON Web Encryption). The payload is merely Base64URL-encoded and can be read by anyone with network or browser console access. Never store database credentials, raw passwords, social security numbers, or sensitive financial data in JWT claims.

Common Gotchas & Troubleshooting

⚠️Invalid Signature Error (SignatureVerificationException) Despite Correct Secret

This error occurs when the secret key is Base64-encoded on the auth server (common in Supabase and Auth0) but entered as raw UTF-8 plaintext in the verifier. Ensure the 'Base64 Secret' toggle is selected if your secret is base64 encoded. Also verify that trailing newline characters ('\n') or quotation marks were not accidentally pasted with the secret.

⚠️Token Expired Error (TokenExpiredError: jwt expired) Immediately After Generation

JWT 'exp' and 'iat' claims are expressed in seconds since the Unix epoch (10 digits), not milliseconds (13 digits). If your backend sets 'exp: Date.now()', the timestamp represents the distant future, or if divided incorrectly, represents year 1970. Use 'Math.floor(Date.now() / 1000) + lifetimeInSeconds', and configure a 60-second clock skew leeway on the verifier.

⚠️RS256 Verification Fails with 'Invalid Key Format' or SPKI PEM Error

RS256 requires a SubjectPublicKeyInfo (SPKI) PEM public key beginning with '-----BEGIN PUBLIC KEY-----' and ending with '-----END PUBLIC KEY-----'. If using a PKCS#1 certificate starting with '-----BEGIN RSA PUBLIC KEY-----', or a JWKS endpoint, convert the key to standard SPKI format or extract the x5c certificate chain into a valid PEM envelope.

⚠️Malformed Token Error: JWT Does Not Contain Exactly Two Period Delimiters

A valid RFC 7519 compact JWT contains exactly two period delimiters separating three Base64URL segments (Header.Payload.Signature). If you copy a token from an HTTP request, remove any leading 'Bearer ' prefix, URL query escape characters ('%2E'), or carriage returns ('\r\n') before parsing.

Frequently Asked Questions

How do you verify a JWT signature and what mathematical components are required?▼

To verify a JWT signature, take the exact Base64URL-encoded header and payload concatenated by a period ('header.payload'), compute the cryptographic digest using the algorithm specified in the header ('alg') and the server's key, and compare the calculated digest against the Base64URL-decoded signature. For HS256, this requires HMAC-SHA256 with a shared secret; for RS256, it requires RSA-SHA256 verification using the issuer's public key.

What is the difference between HS256 and RS256 in JWT authentication?▼

HS256 is a symmetric algorithm where the identical secret key is used to both sign and verify tokens, suitable when the issuer and API gateway share a secure internal perimeter. RS256 is an asymmetric algorithm where the auth server signs tokens with a private key and resource servers verify tokens using a public certificate, allowing microservices and third parties to verify authenticity without exposing the signing key.

Can a JWT token be modified or tampered with without invalidating the signature?▼

No. Any alteration to the header or payload—such as elevating a user role from 'user' to 'admin' or extending the expiration timestamp—changes the cryptographic input. Without possession of the original private key or shared secret, an attacker cannot produce a matching signature, and any compliant verifier will immediately reject the token with an invalid signature error.

Why should you never store sensitive data like passwords or credit cards in a JWT payload?▼

Because standard JWT tokens are only digitally signed (JWS), not encrypted (JWE). The payload is Base64URL-encoded, which provides zero confidentiality. Anyone who intercepts the token in transit, inspects network traffic, or views local storage can instantly decode the Base64URL payload and read all contained claims in plaintext.

What are registered JWT claims and what do iat, exp, and nbf mean?▼

Registered claims are predefined RFC 7519 metadata keys: 'iat' (Issued At) marks the creation epoch timestamp; 'exp' (Expiration Time) defines the timestamp after which the token must be rejected; 'nbf' (Not Before) specifies the earliest time the token is valid; 'iss' identifies the token issuer; 'sub' identifies the principal subject; and 'aud' defines the intended recipient audience.

Related Tools & Utilities

All Tools →
Content Security Policy & CSP GeneratorSecurity

Generate secure Content Security Policy (CSP) headers instantly. Configure script-src, style-src, nonces, and hashes to prevent XSS attacks and fix CSP errors.

Open tool→
Bcrypt Hash Generator & Password VerifierSecurity

Generate cryptographically secure Eksblowfish password hashes with adjustable salt rounds (4-16) and verify candidates locally in browser memory.

Open tool→
HMAC Signature Generator & VerifierSecurity

Calculate and verify RFC 2104 Keyed-Hash Message Authentication Codes across HMAC-SHA256, HMAC-SHA512, HMAC-SHA1, and HMAC-MD5 with timing-safe verification.

Open tool→
Client-Side AES-GCM / CBC Encryptor & DecryptorSecurity

Hardware-accelerated AES-256 authenticated encryption executed strictly in your browser via Web Crypto API. Zero server retention.

Open tool→
RSA Public & Private Key Pair GeneratorSecurity

Generate cryptographically secure RSA public and private key pairs (1024, 2048, 4096-bit) in PKCS#1 and PKCS#8 PEM formats using browser Web Crypto API.

Open tool→
Base58 & Base58Check Encoder / DecoderSecurity

Convert text, hex, and cryptographic public keys to and from Bitcoin and IPFS Base58 / Base58Check formats with SHA-256 double-hash checksum verification.

Open tool→