JWT Decoder & Authentication Debugger
Decode, inspect, and debug JSON Web Tokens, entirely in your browser.
Paste a JWT to decode its header and payload, inspect standard claims, check expiration timing, run rule-based authentication checks, and optionally verify its signature — all processed locally in your browser.
What is a JWT?
A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe way to represent claims — statements about a user or a session — between two parties. JWTs are the backbone of most modern authentication systems: a server issues one after login, and the client sends it back on subsequent requests (typically as an Authorization: Bearer <token> header) so the server can identify the caller without a database lookup on every request.
A JWT is not encrypted. It's signed. Anyone who has the token can read its contents; the signature only proves — when verified — that the contents haven't been altered since the issuer signed them.
How to decode a JWT token
- Paste the token above — a raw JWT, or a full
Authorization: Bearer <token>value. Surrounding whitespace and the Bearer prefix are stripped automatically. - Click Decode token (or press Ctrl/Cmd + Enter from the textarea).
- Review the Overview tab for its structural status, algorithm, timing, and any authentication debugger findings.
- Open Header, Payload, or Claims to explore the decoded JSON, or Verify Signature to check it against a secret or public key.
Don't have a token handy? Use the sample-token menu to load a safe, clearly fictional example.
JWT structure: header, payload and signature
A standard signed JWT is three Base64URL-encoded segments joined by periods: header.payload.signature.
| Segment | Contains | Purpose |
|---|---|---|
| Header | alg, typ, sometimes kid | Declares the signing algorithm and token type |
| Payload | Claims — e.g. sub, iss, aud, exp, plus custom data | The actual statements the token carries |
| Signature | Cryptographic output over header + payload | Lets a verifier detect tampering, given the right key |
Decoding versus verifying a JWT
Decoding reverses the Base64URL encoding on the header and payload — no key required, and this tool (or a one-line script) does it instantly. Decoding tells you what a token claims.
Verifyingrecomputes the signature over the header and payload using the expected key or secret, and checks it matches the signature segment. Verification tells you whether those claims can be trusted — assuming the key itself is trustworthy and hasn't leaked.
A token that decodes cleanly proves nothing about its authenticity. Client-side expiration checks are useful for UX (e.g. proactively refreshing a session), but they never replace server-side signature verification and authorization — a client can always be tricked or bypassed; the server can't be.
How JWT expiration works
Expiration is just a claim inside the payload, not a property enforced by the token format itself. A compliant server reads the exp claim, compares it to the current time, and rejects the request if the token has expired — the same is true for nbf on the other end. Nothing physically stops an expired token from being replayed against a server that forgets to check.
Understanding exp, iat and nbf
| Claim | Meaning | Format |
|---|---|---|
| iat | When the token was issued | Unix timestamp (seconds) |
| nbf | Not valid before this time | Unix timestamp (seconds) |
| exp | Not valid at or after this time | Unix timestamp (seconds) |
The Claims tab converts every timestamp claim into its raw Unix value, UTC date/time, your local date/time, and a relative phrase ("expires in 24 minutes", "expired 2 hours ago") — with a toggle to switch which timezone is shown first.
Common JWT authentication errors
The Overview tab's authentication debugger runs rule-based checks for the issues that show up most often in real integrations, including:
- A missing, empty, or already-past
exp - A future
nbfor unexpectedly futureiat(often clock skew) - A missing
issoraud alg: "none"— an unsigned token, a well-known critical vulnerability class- An asymmetric algorithm without a
kid, which can break key rotation - Sensitive-looking fields (passwords, API keys, card numbers) that should never live in a payload
These are educational warnings to guide your own review, not an absolute verdict on a token's security.
How to verify JWT signatures safely
The Verify Signature tab checks a token's signature locally using your browser's native Web Crypto API — HS256/384/512 with a shared secret, or RS256/384/512 and ES256/384/512 with a PEM-formatted public key. Nothing you enter is sent anywhere.
Crucially, you choose the algorithm to verify against — the tool never silently trusts the algvalue from the token's own header. That distinction matters: a well-known class of attacks (algorithm confusion) tricks a verifier into accepting a token signed with the wrong key type simply because the header asked it to. Real verification code should do the same — pin an explicit allow-list of algorithms rather than reading it from the token.
Never paste a private key anywhere online, including here. Verification only ever needs a public key.
JWT security best practices
- Never store secrets, passwords, private keys, or full card numbers in a payload — it's readable by anyone holding the token.
- Always verify the signature server-side before trusting any claim, on every request.
- Pin an explicit algorithm allow-list in your verification code instead of trusting the token's header.
- Prefer short-lived access tokens plus a separate refresh flow over very long-lived tokens.
- Set and check
audso a token minted for one service can't be replayed against another. - Serve tokens over HTTPS only, and store them somewhere that limits XSS exposure (e.g. an httpOnly cookie where practical).
- Use a maintained JOSE/JWT library for verification — never hand-roll cryptographic signature checking.
JWT usage in Laravel
Laravel Sanctum's default personal access tokens are opaque strings looked up in a database, not JWTs — pasting one into this decoder won't produce a valid three-segment structure, and that's expected. Sanctum trades JWT's self-contained-verification advantage for instant, server-side revocation.
If your Laravel application genuinely issues JWTs — commonly via a package such as tymon/jwt-auth, or a custom-built auth service — this tool decodes and debugs those the same way as any other JWT. See the Code Examples tab for a firebase/php-jwt verification snippet.
JWT usage in Next.js and Node.js
Next.js middleware and Route Handlers commonly verify a JWT from a cookie or Authorization header before allowing a request through — the Code Examples tab includes a ready-to-adapt middleware snippet using jose, the maintained, Edge-runtime-compatible JWT library most current Next.js and Node.js projects reach for. An Express middleware example is included too, for a traditional Node.js API.
More developer tools
Debugging an API that uses JWTs often means moving between a few different tools — the API Response & JSON Inspector is a natural next stop for the response the JWT authenticated. Since JWT segments are just Base64URL, the Base64 Encoder & Decoder is handy for decoding one segment in isolation. Writing tests around your auth middleware? The Test Case Generator scaffolds auth and validation scenarios, and the Regex Tester helps validate token or header formats. Scheduling token refresh or cleanup jobs? See the Cron Expression Builder. And for more free tools like this one, browse the full Developer Resources Directory.
Common questions
Is it safe to paste a JWT into this decoder?+
Decoding happens entirely in your browser — nothing is sent to 92 Nodes or any third party. That said, JWT payloads are readable by anyone who has the token, so treat any token you paste anywhere (including here) as something that could be exposed, and avoid pasting active production tokens on a shared or public device.
Does 92 Nodes upload or store my token?+
No. The token, any secret or public key you enter, and the decoded output never leave your browser. Nothing is written to localStorage, cookies, a URL, a server log, or analytics.
Can a JWT be decoded without the secret?+
Yes. The header and payload are only Base64URL-encoded, not encrypted, so anyone can decode them without any key. Only the signature requires a secret or private key to produce — decoding needs nothing.
Is decoding the same as verifying a JWT?+
No, and this is the most common JWT mistake. Decoding just reads the header and payload. Verifying cryptographically confirms the signature was produced by the expected key and hasn't been tampered with. A token can decode perfectly and still be forged or altered.
How do I know if a JWT is expired?+
Check its exp claim (a Unix timestamp) against the current time. This tool does that for you automatically on the Overview tab, showing an Active, Expired, Not active yet, or No expiration status alongside the exact time remaining.
What are exp, iat and nbf?+
exp (expiration time) is when the token stops being valid. iat (issued at) is when it was created. nbf (not before) is the earliest time it becomes valid. All three are Unix timestamps in seconds, and a server should reject a token outside the exp/nbf window regardless of signature validity.
What does "invalid signature" mean?+
It means the signature doesn't match the header, payload, and key/secret you provided. That can happen because the token was altered, the wrong secret or public key was used, or the algorithm doesn't match what actually signed it.
Can this tool verify HS256 and RS256 tokens?+
Yes — HS256/384/512 (with a shared secret) and RS256/384/512 and ES256/384/512 (with a PEM-formatted public key) are all supported, using your browser's native Web Crypto API. Verification always runs locally; the secret or key is never transmitted.
Why can I read a JWT payload without a key?+
Because a JWT's header and payload are encoded, not encrypted. Encoding (Base64URL) is reversible by design and requires no key — it exists to make binary-unsafe data safe to transport, not to keep it secret. Only the signature depends on a key.
Should passwords or API keys be stored inside a JWT?+
No. Since anyone holding the token can decode the payload, secrets, passwords, private keys, API keys, or full card numbers should never be placed inside one. This tool's authentication debugger flags sensitive-looking field names as a critical finding.
Does Laravel Sanctum use JWT?+
Not by default. Sanctum's standard personal access tokens are opaque random strings looked up in a database, not JWTs — pasting one into this decoder won't produce a valid three-part structure. If your Laravel app issues real JWTs, it's typically through a separate package such as tymon/jwt-auth.
Can I use this tool for Next.js authentication debugging?+
Yes — paste a token issued by your Next.js auth flow (NextAuth/Auth.js, a custom JWT session, or an external identity provider) to inspect its claims and timing. See the Code Examples tab for a ready-to-adapt Next.js middleware verification snippet using jose.
More free resources
Have a project in mind? Let's build it.
Tell us about your goals and we'll get back to you within one business day with next steps.
Book a free call