JWT Decoder & Inspector
Paste a JSON Web Token to decode its header and payload, pretty-print the claims, check expiry, optionally verify the signature (HMAC or RSA/EC), and confirm each segment is valid base64url — all locally in your browser.
Interactive Client Prototype Sandbox
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1900000000
}Disclaimer: This free tool is provided “as is,” without warranties of any kind, and is for general informational purposes only — not professional, legal, financial, medical, tax, or engineering advice. Results may contain errors; verify anything important independently and use at your own risk. We accept no liability for any loss or damage arising from its use. See our Terms of Use for details.
Step-by-Step Guide
Paste a JWT into the input box. The tool immediately splits it into its three dot-separated segments (header, payload, signature), Base64URL-decodes each, and displays the parsed JSON with a validity badge on every segment. Standard time claims — iat (issued at), nbf (not before), and exp (expiration) — are converted from Unix timestamps to human-readable dates, and expired tokens are flagged visually.
Verifying the signature
Expand the 'Verify signature' section to check whether the signature is cryptographically valid. For HMAC-based algorithms (HS256, HS384, HS512) paste the shared secret and indicate whether it is Base64-encoded. For asymmetric algorithms (RS256, RS384, RS512, PS256, ES256, and their variants) paste the issuer's public key in PEM or JWK format, then click Verify. The result is either 'Valid signature' or 'Invalid signature' with the algorithm shown. Verification runs entirely in the browser using the Web Crypto API — your token and key are never sent to a server. A token with alg 'none' has no signature; the tool shows an informational note rather than a pass or fail.
Paste an HS256 JWT such as eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c — the decoder shows alg: HS256, typ: JWT in the header, and sub, name, iat in the payload with the issued-at date humanized. Paste the secret and press Verify to confirm the signature.
Who it's for
Web and API developers, QA engineers, and anyone debugging authentication.
Core Features
- Decodes and pretty-prints the JWT header and payload JSON.
- Shows the algorithm and type, humanizes iat / nbf / exp, and flags expiry.
- Optional signature verification — HMAC secret or RSA/EC public key (PEM or JWK), via Web Crypto.
- Per-segment base64url validity badges; 100% offline (no network, no JWKS fetch).
🛡️ No tracking — your inputs, keys, and details never leave this client sandbox.
What is a JWT and what are the three parts?
A JSON Web Token (JWT) is a compact, URL-safe string used to transmit claims between parties. It consists of three Base64URL-encoded segments separated by dots: the header (algorithm and token type), the payload (the claims — user ID, roles, expiry time, etc.), and the signature (a cryptographic hash of the header and payload using a key, which proves the token has not been tampered with). The header and payload are only encoded, not encrypted — anyone with the token can read them.
Is decoding a JWT safe? Can others read my tokens?
JWT decoding is inherently safe to do locally — the header and payload are Base64URL-encoded, not encrypted, so any party with the token can already read them. However, you should never paste a production JWT into an online tool that sends data to a server, because the token can be used to impersonate the authenticated user until it expires. This tool performs all decoding locally in your browser without any network request.
What is the difference between HS256 and RS256?
HS256 (HMAC-SHA256) is a symmetric algorithm: the same secret is used to both sign and verify the token. This means the server that issues the token and the server that validates it must share the secret. RS256 (RSA-SHA256) is asymmetric: the issuer signs with a private key and validators verify with the corresponding public key, which can be distributed safely. Asymmetric algorithms are preferred in distributed systems where multiple services need to validate tokens without sharing a secret.
What does it mean when a token is expired?
The exp (expiration) claim is a Unix timestamp. When the current time exceeds that timestamp, the token is expired and should be rejected by the server. The decoder flags this visually and shows how long ago it expired. An expired token is not necessarily invalid in the signature sense — the signature may still verify — but it should not be accepted for authorization. Most auth libraries check expiry automatically as part of validation.
What claims are standard in a JWT payload?
RFC 7519 defines several registered claim names: iss (issuer), sub (subject/user ID), aud (audience), exp (expiration), nbf (not before), iat (issued at), and jti (JWT ID for uniqueness). All are optional, but exp and iat are nearly universal. Beyond these, applications add custom claims for roles, permissions, or any other data they want to bundle with the token. The decoder humanizes iat, nbf, and exp automatically.
Why pasting a JWT into the wrong tool is a real security risk
Pasting a JSON Web Token into an online decoder that sends data to a server hands an attacker everything they need to impersonate you until the token expires. JWT payloads are only Base64URL-encoded, not encrypted — they contain your user ID, roles, and session claims in plain text. A token with a 24-hour expiry pasted to a logging server at 9 AM remains exploitable until 9 AM the next day. The right response is to decode tokens locally, in the browser, with no network request — which is exactly what a client-side JWT tool provides.
The three-segment structure
A JWT looks like xxxxx.yyyyy.zzzzz. The first segment is the Base64URL-encoded header, a JSON object specifying the signing algorithm (e.g., {"alg":"HS256","typ":"JWT"}). The second is the Base64URL-encoded payload, a JSON object containing the claims. The third is the signature, computed as HMAC(base64url(header) + '.' + base64url(payload), secret) for HS256, or RSA/ECDSA over the same input for asymmetric algorithms. Because the header and payload are only encoded and not encrypted, anyone with the token can read the claims without knowing the secret — but they cannot create a valid signature without the key.
Stateless authentication
The main appeal of JWTs in API authentication is that they are self-contained. The server encodes the user's identity and permissions into the token at login time and signs it. On every subsequent request, the client sends the token in an Authorization header, and the server verifies the signature and reads the claims without looking up anything in a database. This makes JWT-based auth fast and horizontally scalable, since no session state needs to be shared between server instances.
Security pitfalls to watch for
JWTs are frequently misused. Common pitfalls include: accepting the 'none' algorithm (no signature), which allows forged tokens; not validating expiry (exp); using weak secrets with HMAC algorithms; and storing JWTs in localStorage (vulnerable to XSS attacks). Well-implemented JWT verification always specifies the expected algorithm explicitly, checks exp and nbf, and uses secrets of sufficient length. The 'algorithm confusion' attack exploits servers that accept both RS256 and HS256 — by switching a token's alg to HS256 and signing it with the server's public key as the HMAC secret. Inspecting the alg field of any token you are about to verify is a basic security habit this tool makes easy.