Offline JWT Debugger & Security Auditor
Inspect, decode, and audit authentication JSON Web Tokens strictly in browser memory. Never risk exposing production credentials or OAuth tokens to third-party logging servers. Automatically audits algorithm 'none' exploits, expired timestamps, and missing audience claims.
Raw Encoded JWT
HMAC Signature Verifier
Web Crypto APIFor HS256 tokens, verify the signature locally without sharing your secret key with external servers.
Header specifies an active hashing or signature standard.
Verified with public key. The private signing key never leaves the identity authorization server.
Valid until 10/13/2029, 9:40:00 PM.
{
"alg": "RS256",
"typ": "JWT",
"kid": "auth0-key-01"
}{
"iss": "https://auth.bestutilities.org/",
"sub": "usr_992182af8c",
"aud": [
"https://api.bestutilities.org"
],
"iat": 1728736000,
"exp": 1886640000,
"nbf": 1728736000,
"jti": "8a5d16fd-491c-4f92-8a99-a321eb460e87",
"roles": [
"user",
"developer"
]
}Reserved banner container configured with strict Core Web Vitals CLS = 0 layout preservation.
Anatomy of RFC 7519 JSON Web Tokens (JWT)
A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. Defined in RFC 7519, a standard token consists of three distinct parts separated by dots (.):
Contains metadata declaring the token type (typ: "JWT") and the cryptographic algorithm used to sign the token (alg: "RS256","HS256"). Base64URL-encoded into the first segment.
Carries identity claims and entity properties. Standard registered claims include sub (Subject), iss (Issuer), aud (Audience), and exp (Expiration).
Calculated by taking the encoded header, a period, the encoded payload, and signing them with a secret key (HMAC) or a private key (RSA/ECDSA). Verifies that the sender is authentic and the message was not altered.
The 'alg: none' Vulnerability (CVE-2015-9235)
The JSON Web Signature (JWS) specification includes an algorithm identifier named "none", originally intended for situations where the integrity of the token has already been established by a secure transport channel (such as mutual TLS).
However, flawed authentication libraries naively trusted the header's declared algorithm. An attacker could take a valid token, change their user ID to "admin", alter alg to "none", strip off the signature segment, and submit the modified token. Vulnerable backends accepted the spoofed token as verified.
Authentication servers and API gateways must explicitly enforce an expected algorithm whitelist during verification (e.g., strictly allowing only RS256 or ES256) rather than dynamically selecting the verification method based on the unverified header.
Symmetric vs. Asymmetric Signing in Distributed Architectures
Choosing the right signature algorithm is the foundation of secure token architecture:
| Specification | Symmetric HMAC (HS256 / HS384 / HS512) | Asymmetric Public Key (RS256 / ES256 / Ed25519) |
|---|---|---|
| Secret Management | Single shared secret used for both signing & verification | Private key signs; Public key verifies |
| Microservice Isolation | Poor (Every verifying service knows the signing key) | Excellent (Resource servers only need the public JWKS) |
| Brute-Force Vulnerability | High if secrets are shorter than 256 bits or in dictionaries | Practically immune (2048-bit RSA / 256-bit ECC) |
| Performance Overhead | Ultra-fast (~0.01ms CPU calculation) | Slightly higher math cost (~0.5ms RSA verification) |
How to Handle Token Revocation and Replay Attacks
Because JWTs are stateless, they remain mathematically valid until their exp timestamp elapses. If an employee is terminated or a laptop is stolen, standard JWTs cannot be revoked without architectural planning:
Issue access JWTs with an expiration window of 5 to 15 minutes. Pair them with a revocable, stateful Refresh Token stored in an HTTP-only, SameSite=Strict cookie in your database.
Include a unique JWT ID (jti) claim in every token. When a user logs out, write the jti to a fast in-memory Redis blacklist with a TTL matching the remaining expiration seconds.
Frequently Asked Questions
Many online debuggers send your tokens to remote web servers where access tokens containing sensitive user emails, roles, and cryptographic signatures can be logged, scraped, or retained. Our inspector executes 100% inside your local browser memory.
A valid signature only proves that the payload was not altered after being signed. You must also verify that the token has not expired (exp), matches your expected issuer (iss), and was intended for your service (aud).
No. Standard JSON Web Signatures (JWS) are merely signed and Base64URL-encoded, not encrypted. Any client or proxy can read the claims. Never store sensitive passwords, credit card numbers, or private keys inside a JWT payload.
JWS (JSON Web Signature) represents signed data where the payload is visible to anyone who decodes it. JWE (JSON Web Encryption) encrypts the payload so that only holders of the private decryption key can view the claims.