Developer tool
JWT Decoder
Decode a JSON Web Token (JWT) and inspect what's inside. Paste a token and see its header and payload as readable JSON — decoded locally in your browser, with nothing sent anywhere.
Important: decoding shows you what a token contains. It does not verify the token's signature. Those are different operations, and this page explains both.
Privacy & data handling
Browser processingThis tool processes your input locally in your browser. Nothing is uploaded to a server or sent to an external service.
Interactive tool
JWT Decoder
{
"alg": "HS256",
"typ": "JWT"
}{
"sub": "usr_128904",
"name": "Alex Johnson",
"email": "alex@example.com",
"roles": [
"admin",
"developer"
],
"iat": 1739964000,
"exp": 1799964000,
"iss": "auth.toolkithub.xyz"
}⚠️ Decoding is not signature verification: A decoded JWT shows what the token claims, but does NOT verify that the token was signed with the server's secret key or has not been tampered with. Production authentication must always cryptographically verify the signature on your backend.
• 100% Browser-Local Processing: Your token string is decoded locally in browser memory using Base64URL parsing and is never sent to any server.
Overview
What does JWT Decoder do?
A JWT is a compact, three-part string used to pass claims between parties. This tool splits the token into its three parts and decodes the first two — the header and the payload — into readable JSON.
The header describes how the token was signed (for example, HMAC-SHA256). The payload contains the claims: data like who the token is for (sub), when it was issued (iat), and when it expires (exp). The third part, the signature, is shown as part of the structure but cannot be decoded into meaningful text — it is a cryptographic value, not data.
Crucially, decoding is not verification. Anyone can decode a JWT — the header and payload are just base64-encoded JSON. Verification requires checking the signature against the issuer's key, which this tool does not (and cannot) do without that key.
Under the hood
How does it work?
The token is split on its dot separators. The header and payload are base64url-encoded JSON, so the tool converts the URL-safe base64 back to bytes and parses the JSON into readable, indented form.
The whole operation is local: the token is decoded in browser memory with no network request, so the claims are never transmitted.
If the token is malformed — wrong number of parts, or content that is not valid base64 JSON — the tool reports that it could not be decoded.
Key features
Features of JWT Decoder
Use cases
When should you use JWT Decoder?
Debugging authentication
Inspect what claims a token from your auth provider actually contains — which user, which scopes, when it expires.
Understanding token structure
See the header and payload of a token to understand how your system's tokens are built and signed.
Checking expiry claims
Look at the exp and iat claims to understand why a token might be rejected by your API.
Learning JWTs
Decode sample tokens from documentation to see exactly how the three parts map to header, payload, and signature.
Step-by-step
How to use JWT Decoder
- Step 1
Paste your JWT token.
- Step 2
The tool decodes and displays the header and payload.
- Step 3
Inspect the token contents for debugging.
Real example
Example
Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Decoded
Header
{
"alg": "HS256",
"typ": "JWT"
}
Payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}The signature (third part) cannot be decoded into readable text — it is a cryptographic value.
Technical information
How the details work
A JWT has three parts separated by dots: header.payload.signature. The header declares the signing algorithm and token type. The payload carries claims — standard ones include sub (subject), iss (issuer), aud (audience), iat (issued at), and exp (expiration). The signature is produced by signing the header and payload with a secret key or private key.
Because the header and payload are only base64url-encoded — not encrypted — anyone who has a token can read its claims. This is by design: JWTs are meant to be readable, with the signature providing integrity. It also means you should never put secrets inside a token's payload.
Verification is a separate operation that requires the signing key. With HMAC (symmetric) signing, the verifier uses the same secret; with RSA/ECDSA (asymmetric), the verifier uses the issuer's public key. Without the appropriate key, signature verification is impossible — no decoder can do it for you. Expired or incorrectly signed tokens should be rejected by your application even though they decode fine.
Privacy & security
Your data stays yours
Your token is decoded entirely in your browser. Nothing is transmitted, logged, or stored.
Local processing — files stay in your browser
- Decoding runs locally — the token never leaves your device.
- Nothing is retained after you close the tab.
- Keep in mind that a JWT's claims are readable by anyone who holds the token, so avoid tokens containing sensitive personal data.
- Analytics only record the page visit.
Limitations
What this tool does not do
- Does not verify signatures — verification requires the issuer's signing key.
- Does not check whether a token is expired or otherwise invalid for your application.
- Malformed tokens are reported as undecodable.
- The signature itself cannot be decoded into readable text.
Frequently asked questions
Common questions about JWT Decoder
Can a JWT decoder reveal the original password?
No. A JWT payload contains claims, not passwords — and putting a password in a token would be a serious security mistake, since anyone with the token can read it. If a token you decode contains sensitive data, flag it to whoever issued it.
Does decoding a JWT verify its signature?
No. Decoding only base64-decodes the header and payload, which anyone can do. Verifying the signature requires the issuer's signing key and is a separate step your application must perform before trusting a token.
What information is stored in a JWT?
The payload contains claims — typically the subject (sub), issuer (iss), issued-at (iat), and expiration (exp), plus whatever custom claims the issuer adds. These are readable by anyone holding the token, which is why tokens should not carry secrets.
Is it safe to paste a JWT into an online decoder?
On this site, yes — decoding happens locally in your browser and the token is never transmitted. But be careful with any decoder you haven't vetted, and remember that real tokens may contain personal data. Only paste tokens you own or are authorized to inspect.
Why are there three parts in a JWT?
The three dot-separated parts are header, payload, and signature. The header describes the signing algorithm, the payload carries the claims, and the signature proves the first two parts haven't been tampered with (when verified with the right key).
Why does the tool say a token is invalid?
A token needs exactly three parts, and the header and payload must be valid base64url-encoded JSON. If either condition fails, the token is malformed and cannot be decoded.
How is expiration (exp) time calculated and displayed?
The tool reads the numeric 'exp' Unix timestamp from the payload, calculates the date in UTC and local time, and checks if Date.now() / 1000 has passed to show if the token is Active or Expired.
What is the difference between JWS (signed) and JWE (encrypted) tokens?
JWS tokens have three base64url-encoded parts (header.payload.signature) where the payload is readable plaintext. JWE tokens have five parts and encrypt the payload ciphertext. This decoder is designed for standard JWS tokens.
Why should API secrets or passwords never be placed in a JWT payload?
JWT payloads are merely base64url-encoded, not encrypted. Anyone who intercepts the token or inspects network traffic can decode and view the entire payload in plaintext.
What is the 'nbf' (Not Before) and 'iat' (Issued At) claim?
'iat' records the exact second the token was created. 'nbf' specifies that the token must not be accepted by servers before that timestamp.
Related tools
Base64 Encoder
Encode and decode Base64 strings with validation. Useful for embedding binary data in JSON or HTML.
API Tester
NewGenerate curl commands and API test requests for common HTTP methods and endpoints.
Regex Generator
NewGenerate a ready-to-use regex for common cases such as email or URL matching.
Related guides
Practical articles to help you get the most out of this tool and related workflows.
Security
Why Browser-Based Tools Are the Safest Way to Handle Sensitive Documents
Discover why processing files in your browser protects privacy better than desktop or cloud alternatives.
Developer
JWT Explained: What a JSON Web Token Actually Is
Header, payload, signature — and why decoding a JWT is not the same as verifying it. A security-accurate explainer.
Need another tool?
Browse the full catalog and jump between related workflows with SEO-friendly internal links.
Explore all tools