100% Client-SideConverters

Online JWT Decoder & Token Inspector (Zero-Upload Privacy)

Decode, inspect, and verify JSON Web Tokens (JWT) directly inside your browser. No auth tokens or secret keys are ever transmitted over the network or logged to cloud servers, satisfying strict enterprise privacy, SOC2, and GDPR Article 28 compliance.

Loading workspace...

#How to Use This Tool

1Paste your raw JWT token into the input editor (e.g., copied from browser DevTools, API responses, or Authorization headers).
2The token is immediately parsed into its Header, Payload, and Signature components with automatic JSON syntax highlighting.
3Review the Claims table for real-time expiration countdowns, issued-at timestamps, and audience validation.
4Optionally enter your HMAC secret or RSA public key to verify signature authenticity client-side using the Web Crypto API.

#Mathematical Formula & Standards

A JSON Web Token (RFC 7519) consists of three Base64URL-encoded segments delimited by periods: Header.Payload.Signature. The Header specifies the cryptographic algorithm (e.g., HS256, RS256) and token type (JWT). The Payload contains registered claims (iss, sub, aud, exp, nbf, iat) alongside custom application claims. Standard expiration is validated against current Unix time (exp < Math.floor(Date.now() / 1000)). In JWS (RFC 7515), signatures are generated by hashing Header.Payload using HMAC-SHA or signing with an asymmetric private key.

#Edge Cases & Technical Considerations

Unsecured JWTs (alg: "none")

Some debug or internal tokens specify alg: "none" and lack a signature segment (or end with a trailing dot). While technically valid per RFC 7519, production authentication systems must reject unsigned tokens to prevent signature bypass vulnerabilities (CVE-2015-9235).

Clock Skew & Expiration Leeway

Distributed authentication servers often allow 30 to 300 seconds of clock skew tolerance when evaluating exp and nbf claims to compensate for server drift. Our inspector shows exact Unix timestamps and relative time deltas.

Base64 vs Base64URL Padding

JWT tokens strictly require Base64URL encoding (RFC 4648 §5), which replaces "+" with "-", "/" with "_", and strips trailing "=" padding characters. Our decoder automatically re-pads and normalizes URL-safe strings before decoding UTF-8 bytes.

JWS (Signed) vs JWE (Encrypted)

Standard JWT tokens are signed (JWS), meaning payloads are publicly readable by anyone holding the token. Never store raw unencrypted passwords, credit card numbers, or sensitive credentials inside standard JWT claims without using JWE (RFC 7516).

#Frequently Asked Questions

Q:Is it safe to paste corporate or production JWT tokens here?

Yes. regula.tools executes 100% in your browser using client-side JavaScript and the native Web Crypto API. Your token is never uploaded to any remote server or stored in telemetry, complying with corporate security and GDPR policies.

Q:Can this tool verify HMAC and RSA signatures?

Yes. You can optionally provide an HMAC secret (HS256, HS384, HS512) or RSA public key (RS256, RS384, RS512) to verify signature authenticity locally via crypto.subtle.verify.

Q:Why does my token say "Expired"?

The token contains an "exp" (expiration time) claim representing a Unix timestamp in seconds that has already passed. Authentication servers will reject expired tokens.

Have feedback or feature requests?

Help us improve this utility. Share suggestions, report edge cases, or request new features directly.

Send Feedback