Developer & data utilities
JWT Decoder
Decode JWT tokens to inspect header, payload, and signature claims client-side.
Run JWT Decoder online
In-browserDocument processing runs on your device. External resources may still load.
Enable JavaScript to use the interactive tool. Read the instructions, limitations and FAQs below before starting.
The JWT Decoder allows you to inspect JSON Web Tokens — decoding the header, payload, and signature without needing a secret key. JWT (RFC 7519) is the universal authentication token format used by virtually every modern web API, mobile application, and single sign-on system.
A JWT consists of three Base64url-encoded sections: Header (algorithm and token type), Payload (claims — user ID, roles, expiry, issued-at, and custom fields), and Signature (cryptographic proof of authenticity). Our decoder shows all three sections in formatted JSON, highlights the expiry status, and extracts key claims.
Security note: this tool never sends your JWT to any server. All decoding happens in your browser using JavaScript's atob(). However, JWTs should still be treated as sensitive credentials — do not paste production tokens in untrusted tools. Our tool is 100% client-side with no network requests.
How to use this utility
- Use the controls below—paste text, pick files, or adjust options as described on the tool.
- Click the main action button. Processing runs in your browser on this device.
- Download or copy the output. Check the processing note for any external services used by this operation.
Common use cases
- Debugging authentication failures by inspecting JWT claims and expiry
- Verifying that JWT contains correct roles and permissions
- Checking iat (issued at) and exp (expiry) timestamps in token claims
- Inspecting OAuth 2.0 and OpenID Connect tokens from Google, GitHub, or Auth0
- Validating custom claims in internal microservice authentication tokens
Tips for best results
- 1Always verify JWT signature on the server — decoding alone does not verify authenticity
- 2The exp claim is a Unix timestamp — check it matches expected expiry duration
- 3If you see iss (issuer) claim, verify it matches your expected token issuer
- 4Sub (subject) typically contains the user ID — verify it matches the authenticated user
- 5Never log full JWTs in application logs — they are authentication credentials
Frequently asked questions
- Is Konnect2Tools free?
- Yes. These in-browser tools are completely free to use with no account required for core functionality.
- Do my files leave my device?
- Browser document operations run locally, except where the operation uses an external service, such as AI summarisation. Read the processing note before using sensitive inputs.
- Is the JWT Decoder tool safe to use?
- Local operations process document content on your device. External-service operations may send inputs as described in the processing note. Keep originals and inspect the output.
- Is it safe to decode a JWT?
- Decoding reveals the contents but does NOT verify authenticity — anyone can decode a JWT. Verification (checking the signature with the secret key) must happen server-side. Never trust decoded claims from a JWT unless the signature has been cryptographically verified on the server.
- What are standard JWT claims?
- Standard registered claims: iss (issuer), sub (subject/user ID), aud (audience), exp (expiry — Unix timestamp), nbf (not before), iat (issued at), jti (JWT ID). Public claims: email, name, roles, permissions. All claims are readable by anyone — never put passwords or sensitive secrets in JWT payloads.
- What does 'token expired' mean?
- The exp (expiration) claim is a Unix timestamp. When the current time exceeds exp, the token is expired and the server will reject it. Clients must refresh the token before expiry using a refresh token (for OAuth flows) or re-authenticate. Our decoder shows whether the token is currently valid or expired.
- What is the difference between HS256 and RS256 algorithms?
- HS256 uses a shared HMAC secret key for both signing and verification — simpler but requires sharing the secret. RS256 uses RSA asymmetric keys: private key signs, public key verifies. RS256 is preferred for microservices where verification should happen without sharing the signing secret.
Related tools
Continue with another utility in developer & data utilities.