JWT Decoder
Paste a JWT (JSON Web Token) and decode its header and payload. Useful for developers to inspect JWT contents without verification.
Security Notice
This tool only decodes JWT tokens - it does not verify signatures. Never paste sensitive or production JWTs into online tools.
Sample JWT
JWT Token Input
Decoded Output
Decoded JWT will appear here
JWT Structure
header.payload.signatureAbout JWT Decoder
A secure JWT (JSON Web Token) decoder that allows you to inspect and analyze the contents of JWT tokens without requiring verification. This tool safely decodes the header and payload sections of JWT tokens, displaying their contents in a readable JSON format for debugging and development purposes.
Why use a JWT Decoder?
When working with JWT tokens in authentication systems, you often need to inspect their contents for debugging, testing, or verification purposes. This decoder provides a quick and secure way to view JWT payloads without exposing sensitive information or requiring server-side verification, making it essential for API development and troubleshooting.
Who is it for?
Perfect for backend developers, API engineers, security professionals, and DevOps teams working with JWT-based authentication systems. Essential for anyone debugging authentication flows, testing API tokens, or learning about JWT structure and implementation in web applications.
How to use the tool
Paste your JWT token into the input field (including the full token with all three parts)
The tool automatically decodes and displays the header information
Review the payload section to see claims, expiration dates, and other token data
Analyze the token structure and verify the algorithm and other security parameters
Use the decoded information for debugging authentication issues or API integration
Frequently Asked Questions
How do I decode a JWT?
Paste the JWT token (the three-part string separated by dots: header.payload.signature) and the tool splits and base64url-decodes the header and payload, displaying them as JSON. The header reveals the algorithm (alg: HS256, RS256, ES256, EdDSA) and key ID (kid). The payload reveals the claims (sub, iat, exp, iss, aud, plus any custom claims). The signature is base64-encoded binary — it's used for verification, not human-readable. Decoding is just base64-decoding the first two parts; no key or secret needed. The whole operation is local — your token never touches a server.
Is it safe to decode JWTs online?
For testing and debugging, yes — this tool decodes entirely in your browser, with no network requests, no logging, no telemetry. Verify in DevTools' Network tab: decoding produces zero HTTP traffic. The token never leaves your device. However, treat any JWT you paste here as if it might be exposed: don't paste production tokens that include sensitive PII in claims, and don't paste tokens that are still valid (haven't expired). For production debugging, use your application's local JWT library (jose for Node, PyJWT for Python, jsonwebtoken for Java) and pipe tokens through stdin without ever putting them in a browser or shared service.
What are JWT claims?
Claims are the fields in the JWT payload — the data the token carries. Standard (registered) claims defined by RFC 7519: iss (issuer), sub (subject — usually user ID), aud (audience — who the token is for), exp (expiration time), nbf (not before), iat (issued at), jti (unique JWT ID). Public claims are domain-specific but registered with IANA. Private claims are application-specific — anything you put in the payload (email, role, permissions, tenant). Critical: claims are not encrypted, just base64-encoded — anyone with the token can read them. Don't put secrets in JWT claims. Verify the signature before trusting any claim's value.
Can someone tamper with a JWT after I decode it?
Yes — JWTs are signed, not encrypted. The base64-encoded header and payload are fully readable and modifiable. What protects the token is the signature: if anyone changes the header or payload, the signature no longer matches, and a properly-configured verifier rejects the token. This is why decoding (without verification) tells you what claims the token CONTAINS, but not whether those claims are AUTHENTIC. Always verify the signature before trusting any claim — every JWT library has a verify() function that takes the token plus the matching secret (for HS*) or public key (for RS*/ES*/EdDSA). Decoding-without-verifying is fine for inspection; never for authentication decisions.
What's the difference between HS256, RS256, and ES256?
These are the algorithms used to sign the JWT. HS256 = HMAC-SHA256, symmetric (one shared secret). Anyone with the secret can both sign and verify. Fast, simple, but requires sharing the secret. RS256 = RSA + SHA-256, asymmetric (private key signs, public key verifies). Use when the verifier shouldn't be able to forge tokens — typical for OAuth providers distributing public keys via JWKS endpoints. ES256 = ECDSA P-256 + SHA-256, asymmetric and faster than RS256 with smaller signatures. EdDSA (Ed25519) is the modern alternative, even faster and simpler. For internal services: HS256. For cross-service or public verification: ES256 or EdDSA.
What does the 'exp' claim mean and why does it matter?
exp (expiration time) is the Unix timestamp (seconds since 1970-01-01) when the token stops being valid. A properly-configured verifier rejects any token whose exp is in the past. Typical lifetimes: access tokens 5-60 minutes, refresh tokens hours to weeks, ID tokens 5-30 minutes. Long-lived tokens are risky — once leaked, they remain valid until expiration, with no way to revoke (JWT's stateless design has no built-in revocation). Best practice: keep access tokens short, use refresh tokens (or session cookies) for the long-lived state, and maintain a server-side blocklist for revoked-before-expiry tokens. If the token in this tool shows exp in the past, your application would reject it.
Can I decode an encrypted JWT (JWE) with this tool?
No — JWTs come in two main flavors. JWS (JSON Web Signature, the most common) is signed but not encrypted: the header and payload are base64-encoded but plain-text-readable. JWE (JSON Web Encryption) is encrypted: the payload is ciphertext you can't decode without the encryption key. The two formats are visually distinguishable: JWS has three dot-separated parts (header.payload.signature); JWE has five (header.encrypted_key.iv.ciphertext.tag). This tool handles JWS, which covers 99%+ of real-world JWTs. For JWE inspection, you need the key — and at that point, you should use your application's JWT library directly rather than a browser tool.
What is the 'alg' header field and why is 'none' dangerous?
The alg field declares which algorithm signed the JWT. Modern values: HS256, RS256, ES256, EdDSA, etc. The 'none' value means 'this token is unsigned' — RFC 7519 includes it for development testing, but a famous vulnerability class lets attackers strip the signature, change the alg to 'none', and submit forged tokens. Any properly-configured verifier should reject alg=none unconditionally (and reject alg confusion — e.g., a token claiming HS256 when the verifier expects RS256). When decoding shows alg=none in a production token, that's a critical security finding. Your verifier should explicitly require an allowed-list of algorithms, never trust the token's declared alg.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.