Connecting to OmniTools before opening this tool…
Only a temporary connection check is sent. Your files and tool inputs stay in your browser.
How JWT Token Inspector & Decoder works
The JWT Debugger decodes and inspects JSON Web Tokens by splitting the three Base64URL-encoded segments (header, payload, signature) separated by period delimiters, decoding each segment independently, and presenting the parsed JSON objects in formatted readable structure. JWTs follow the RFC 7519 specification comprising a header declaring the algorithm (alg) and token type (typ), a payload containing registered claims (iss, sub, aud, exp, nbf, iat, jti) alongside custom application claims, and a cryptographic signature computed over the concatenated header and payload.
The decoding engine applies RFC 4648 Base64URL decoding—which substitutes standard Base64 + and / characters with URL-safe - and _ variants and omits padding = characters—to each dot-separated segment. The header and payload decode to UTF-8 JSON strings parsed into navigable object trees. The signature segment decodes to raw bytes displayed in hexadecimal format for inspection. Expiration validation compares the exp claim Unix epoch timestamp against the current system clock to determine token validity status.
Critically, this tool performs decoding and inspection only—it does not verify cryptographic signatures since verification requires the secret key or public certificate which should never be entered into any online tool. All Base64URL decoding and timestamp calculations execute client-side in browser memory without transmitting token data externally.
How to use JWT Token Inspector & Decoder
1. Paste JWT Token String
Enter the complete JWT string (eyJhbG... format) into the input field. The parser validates the three-segment dot-delimited structure before processing.
2. Decode Header Segment
The first Base64URL segment decodes to reveal the signing algorithm (HS256, RS256, ES256, etc.), token type, and optional key ID (kid) parameters used in token generation.
3. Inspect Payload Claims
The second segment decodes to display all registered claims (issuer, subject, audience, expiration, issued-at) and custom application-specific data embedded in the token payload.
4. Validate Expiration Status
The engine compares the exp claim Unix timestamp against current system time to indicate whether the token has expired, remains valid, or lacks expiration enforcement.
Key features and technical specifications
RFC 4648 Base64URL Decoding
Standards-compliant decoder handles URL-safe alphabet substitution (- for +, _ for /) and optional padding omission specific to JWT encoding requirements.
Claim Timestamp Validation
Automatic comparison of exp (expiration) and nbf (not before) Unix epoch claims against current system clock provides instant token validity status indicators.
Formatted JSON Display
Decoded header and payload objects render with syntax highlighting and proper indentation for easy navigation of nested claims, arrays, and role assignments.
Signature Hex Inspection
Raw signature bytes decode to hexadecimal representation for algorithm identification and byte-length verification without exposing any secret key material.
Decoding claims does not verify a token
Anyone can construct a token-shaped string containing convincing user claims. Trust requires signature verification with the expected key and algorithm, plus issuer, audience and expiry checks. Use decoded claims for debugging only, and avoid sharing live bearer tokens in screenshots, issue trackers or messages.
Backend API Developers
Debug authentication failures by inspecting JWT claims, verifying issuer and audience values, checking expiration timestamps, and confirming custom role scopes during API integration testing.
Frontend Authentication Engineers
Examine stored access tokens and refresh tokens to understand claim structures, verify user identity data, and diagnose session management issues in SPA authentication flows.
DevOps & Security Teams
Audit OAuth 2.0 and OpenID Connect token issuance by decoding JWTs from identity providers to verify claim accuracy, algorithm selection, and expiration policy compliance.
Mobile App Developers
Inspect authentication tokens received from backend APIs during mobile app development to debug login flows, token refresh mechanisms, and permission scope assignments.
Frequently asked questions
Does this tool verify the JWT cryptographic signature?
No. Signature verification requires the HMAC secret key, RSA public key, or ECDSA certificate used during token signing. Entering secret keys into any web tool creates severe security risks. This tool decodes and displays token contents for inspection purposes only. Always verify signatures server-side using your identity provider SDK or JWT library with securely stored key material.
What is the difference between HS256 and RS256 algorithms?
HS256 (HMAC-SHA256) uses a shared symmetric secret key for both signing and verification—anyone with the key can forge tokens. RS256 (RSA-SHA256) uses asymmetric cryptography: the issuer signs with a private key while verifiers use the corresponding public key, preventing token forgery without private key access. The JWT header alg claim indicates which algorithm was used.
How does the expiration check work?
The exp claim contains a Unix epoch timestamp (seconds since January 1, 1970 UTC). The debugger reads this value, converts it to a JavaScript Date object, and compares it against the current system time. If the current time exceeds the exp value, the token is flagged as expired. Similarly, the nbf (not before) claim indicates when the token becomes valid.
Is it safe to paste production JWTs into this tool?
The decoding executes entirely in your browser without network transmission, making it technically secure. However, best practice dictates never pasting production tokens containing sensitive PII, admin privileges, or confidential claims into any web-based tool. Use staging environment tokens or redacted samples for debugging workflows.
What are standard registered JWT claims?
RFC 7519 defines seven registered claims: iss (issuer identifier), sub (subject/principal), aud (intended audience), exp (expiration time), nbf (not valid before), iat (issued at time), and jti (unique token identifier). None are mandatory but exp and iss are strongly recommended. Applications also embed custom private claims for roles, permissions, and user profile data.
Do I need an internet connection, and are my inputs uploaded?
An internet connection is required to open tools and refresh a temporary session. Processing stays on your device; the handshake sends a random challenge, not files or text inputs. Libraries, fonts or models may download. Local processing cannot remove risks from an untrusted device or extension.