LocalDevTools 100% Free & Client-Side

JWT Token Inspector & Decoder

/inspect/

RFC 7519 Compliant · Expiry Timestamps · 100% Client-Side Privacy

Load Presets:
Encoded JWT String(Header · Payload · Signature)
💡 Automatically strips "Bearer " prefix390 characters
✅
Token Active(Expires in 2396d 3h 2m)
5/18/2033, 3:33:19 AM
HeaderAlgorithm & Key Info
{
  "alg": "HS256",
  "typ": "JWT",
  "kid": "v1"
}
PayloadUser Identity & Claims
{
  "sub": "usr_0a1b2c3d4e",
  "name": "Alex Chen",
  "email": "[email protected]",
  "role": "Senior Software Engineer",
  "iat": 1704067200,
  "exp": 1999999999,
  "iss": "https://auth.devtoolkit.live",
  "aud": "https://api.devtoolkit.live"
}
Recognized Claims Inspector:
subSubject (Principal subject identifier / user ID)
usr_0a1b2c3d4e
nameFull Name of the subject
Alex Chen
emailEmail address of the subject
[email protected]
roleUser Authorization Role / Scope
Senior Software Engineer
iatIssued At (Unix timestamp when token was created)
1704067200
expExpiration Time (Unix timestamp after which token is invalid)
1999999999
issIssuer (Principal that issued the JWT)
https://auth.devtoolkit.live
audAudience (Target recipients for this token)
https://api.devtoolkit.live
SignatureHMAC-SHA256 / RSA Validation
🔒 100% In-Browser WebCrypto
🔒100% Private Client-Side: Tokens and secrets never leave your browser memory. No telemetry or server logging.RFC 7519 JSON Web Token (JWT) Compliant

What is a JSON Web Token (JWT) and How Does It Work?

A JSON Web Token (JWT) is an open, industry-standard (RFC 7519) method for representing claims securely between two parties. JWTs are widely employed in modern web applications, Single Page Apps (SPAs), microservice architectures, and mobile APIs for stateless user authentication and granular authorization (role-based access control).

A standard compact JWT is composed of three distinct base64url-encoded string segments concatenated by periods (.):

  • Header: Specifies the cryptographic signing algorithm (such as HS256 or RS256) and token type (JWT).
  • Payload: Encapsulates the actual identity claims (such as subject ID sub, expiration exp, user email, and administrative role arrays).
  • Signature: Generated by hashing the combined header and payload using a secret key or private certificate, guaranteeing that neither the header nor payload has been tampered with in transit.

Unlike traditional session identifiers stored in centralized server caches, JWTs are completely self-contained. Any microservice with the public certificate or HMAC secret can verify identity claims without hitting an external database.

How to Use the LocalDevTools JWT Inspector

  1. Paste your token: Paste your raw JWT into the left input pane. The tool automatically detects and removes any preceding Bearer prefixes or surrounding quotation marks.
  2. Inspect claims: Examine the real-time decoded Header and Payload on the right. Recognized claims like exp (expiration) and iat (issued at) are translated into your local time zone alongside human-readable countdowns ("Expires in 2 hours" or "Expired 3 days ago").
  3. Verify signature: If your token uses HMAC-SHA256 (HS256), enter your secret key into the verification bar to confirm cryptographic integrity client-side.
  4. Download or copy: Click Copy Payload JSON or Download Claims .json to easily integrate decoded claims into your unit test mocks or documentation.

Frequently Asked Questions (FAQ)

Is it safe to paste confidential production JWTs into this tool? ↓

Yes, 100% safe. LocalDevTools executes decoding and cryptographic verification entirely within your browser memory using native JavaScript and the standard Web Crypto API (crypto.subtle). Neither your token nor your secret key is ever transmitted over the network or saved to any server log. You can even use this tool completely offline.

Can anyone read the payload of a JWT without the secret key? ↓

Yes! A fundamental concept of standard JWTs (JWS) is that they are signed, not encrypted. The base64url encoding is merely a data serialization format, not encryption. Anyone who intercepts a token can read its payload claims. Therefore, you should never store sensitive secrets, passwords, or credit card numbers in a standard JWT payload.

What is the difference between HS256 and RS256? ↓

HS256 (HMAC with SHA-256) is a symmetric algorithm using a single shared secret key for both creating and verifying the signature. RS256 (RSA Signature with SHA-256) is an asymmetric algorithm using a private key to sign the token and a publicly distributed public key to verify it. RS256 is ideal for third-party identity providers (such as Auth0, Google Identity, and Keycloak) because client applications can verify tokens without knowing the private signing key.