JWT Decoder: How to Decode and Inspect JWT Tokens Online
Decode and inspect JWT tokens to view headers, claims, and expiry instantly. Understand token structure without sending tokens to external servers.
Try the free online tool
Runs entirely in your browser — no signup, no uploads.
JSON Web Tokens (JWTs) are the backbone of modern authentication and authorisation systems. They carry user identity, roles, permissions, and session metadata in a compact, self-contained format. Knowing how to inspect a JWT is an essential skill for any developer working with APIs, OAuth 2.0, OpenID Connect, or stateless authentication systems.
A JWT looks like a long, opaque string with two dots in it, but it is actually three Base64url-encoded JSON objects separated by periods. The first part is the header (algorithm and token type), the second is the payload (claims), and the third is the signature. You can decode and read the first two parts with no cryptographic knowledge; the signature simply verifies authenticity.
This tool decodes any JWT directly in your browser, with no network requests. Paste your token and instantly see the header and payload formatted as readable JSON, along with the expiry time, issued-at time, and a human-readable summary of the standard claims.
What Is a JWT?
A JSON Web Token is a compact, URL-safe string defined in RFC 7519. It consists of three Base64url-encoded parts joined by dots: header.payload.signature. The header specifies the token type (JWT) and the signing algorithm (HS256, RS256, ES256, etc.). The payload contains claims, which are statements about the subject: who they are, what they can do, and when the token expires.
Standard registered claims include iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Applications can add any additional custom claims. The payload is not encrypted by default; anyone with the token can read it. Encryption requires JWE (JSON Web Encryption).
The signature is computed by signing the Base64url-encoded header and payload with a secret key (for HMAC algorithms like HS256) or a private key (for asymmetric algorithms like RS256 and ES256). The signature ensures that the token has not been tampered with since it was issued. Decoding a JWT does not verify the signature; you need the key for that.
How to Use This Tool
Decoding a JWT to inspect its contents is a quick process.
- 1
Paste the JWT
Copy the JWT from your API response, browser local storage, network request, or authentication header and paste it into the input field.
- 2
View the header
The tool displays the decoded header JSON showing the algorithm (alg), token type (typ), and any key ID (kid) claims.
- 3
Inspect the payload claims
Read the decoded payload to see the subject (sub), issuer (iss), expiry (exp), roles, and any custom application claims.
- 4
Check the expiry
The tool converts the exp Unix timestamp to a human-readable date and tells you whether the token is currently valid, expired, or not yet active.
- 5
Examine the signature section
The raw signature bytes are displayed for reference, but signature verification requires the secret or public key.
Common Use Cases
JWT decoding is useful throughout the development and debugging lifecycle.
- Debugging authentication failures by checking whether a token is expired or missing required claims.
- Verifying that an identity provider is sending the correct claims (roles, email, subject) in issued tokens.
- Inspecting OAuth 2.0 access tokens and OpenID Connect ID tokens during integration testing.
- Understanding the algorithm and key ID claims in the header when setting up token validation.
- Reading custom claims added by your authorisation service to verify business logic is working correctly.
- Checking token expiry times to diagnose session management issues in single-page applications.
Tips and Best Practices
- Never paste production user tokens into online tools you do not control; use a local browser-based decoder or a trusted CLI tool like jwt-cli.
- Remember that decoding is not validation; a decoded token may be expired, issued by the wrong issuer, or intended for a different audience. Your backend must validate all claims.
- Store JWTs in httpOnly cookies rather than localStorage to protect them from XSS attacks in browser applications.
- Keep token expiry times short (15 minutes to 1 hour for access tokens) and use refresh tokens for long-lived sessions to limit the window of exposure if a token is stolen.
- Use the kid claim in the header to implement key rotation without downtime; your validation logic can look up the correct public key by ID.
JWT Algorithms Explained
The alg claim in the JWT header specifies how the token was signed. HMAC algorithms (HS256, HS384, HS512) use a shared secret key known to both the issuer and the validator. They are simple to implement but require the secret to be distributed to every service that validates tokens.
RSA algorithms (RS256, RS384, RS512) use a public/private key pair. The issuer signs with the private key; validators verify with the public key, which can be shared openly via a JWKS (JSON Web Key Set) endpoint. ECDSA algorithms (ES256, ES384, ES512) offer similar security to RSA with smaller key sizes.
The none algorithm (no signature) must be explicitly rejected by all JWT validators. The notorious none algorithm attack exploited validators that accepted unsigned tokens. Always ensure your library explicitly rejects the none algorithm.
Frequently Asked Questions
Is it safe to decode a JWT? Does decoding expose the signature key?
Decoding a JWT is safe. The header and payload are just Base64url-encoded JSON and require no key to decode. The signature cannot reveal the signing key; it is a one-way operation. What you should be careful about is pasting real user tokens into third-party online tools, as the tool operator could log and misuse them.
What is the difference between decoding and verifying a JWT?
Decoding reads the header and payload by reversing the Base64url encoding. Anyone can decode any JWT. Verification checks that the signature is valid using the signing key, that the token has not expired (exp), that it was issued by the expected issuer (iss), and that it is intended for the correct audience (aud). Decoding without verification does not prove the token is trustworthy.
Why does the exp claim show a Unix timestamp instead of a date?
JWT standard claims use Unix timestamps (seconds since January 1, 1970 UTC) for time values. This format is compact, timezone-neutral, and easy to compare numerically. This decoder converts the timestamp to a human-readable date for display. To convert a Unix timestamp manually, use new Date(exp * 1000).toISOString() in JavaScript.
Can I decode a JWT without splitting it manually?
Yes. This tool accepts the full JWT string and splits it at the dots automatically. If you want to do it programmatically in JavaScript: const [header, payload] = token.split('.').slice(0, 2).map(part => JSON.parse(atob(part.replace(/-/g, '+').replace(/_/g, '/')))).
What is a JWKS endpoint and how does it relate to JWT decoding?
A JSON Web Key Set (JWKS) endpoint is a URL published by an identity provider that lists the public keys used to sign JWTs. The kid claim in the JWT header identifies which key was used. Token validators fetch the JWKS, find the matching key by kid, and use it to verify the signature. This enables key rotation without coordinating with all token consumers.
Why do some JWTs have five parts instead of three?
JWTs with five dot-separated parts are actually JWEs (JSON Web Encrypted tokens). JWE adds confidentiality by encrypting the payload. The five parts are: protected header, encrypted key, initialisation vector, ciphertext, and authentication tag. Standard JWTs have three parts; JWEs have five. You cannot read the payload of a JWE without the decryption key.
What happens if a JWT is tampered with?
If any part of the JWT header or payload is modified, the signature will no longer match. A proper JWT validator will reject the token with a signature verification error. This makes JWTs tamper-evident: you cannot change the claims without knowing the signing key. However, if a validator fails to check the signature, tampering goes undetected.
Ready to use this tool?
Free, instant, no account required. Runs entirely in your browser.