JWT Decoder
Paste a JSON Web Token to decode its header and payload, inspect every claim, and check expiry — instantly, in your browser. Decode-only: this tool reads the token, it does not verify the signature.
This decoder runs entirely in your browser. Your token is never uploaded, logged, or sent anywhere. It is decoded with atob and parsed locally. Never paste a production token into a tool you do not trust.
Header
Decoded algorithm and token type appear here.
Payload
Decoded claims appear here.
Signature (not verified)
none
This tool decodes only. It does not verify the signature, so it cannot tell you whether the token is authentic. Always verify the signature server-side with the issuer's key before trusting any claim.
Decoding is not verifying — and the difference matters
A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header names the signing algorithm and token type. The payload carries the claims — who the token is about, what it grants, and when it expires. The signature is a keyed hash over the first two parts. This tool splits on the dots and base64url-decodes the first two segments so you can read them. It deliberately stops there.
The single most important thing to understand about JWTs is that encoding is not encryption. The payload is plain JSON anyone can read with two lines of code. The signature does not hide the contents — it only proves the token has not been altered since it was signed. So never put a password, a full credit card number, or any other secret in a JWT payload. If the data must stay confidential, reach for an encrypted token (JWE), not a signed one.
Why decode-only is a deliberate choice. Verifying a signature requires the signing key, and the security of the whole scheme depends on doing that verification correctly, server-side, with the algorithm pinned. A browser tool that asked you to paste your signing secret would be teaching a dangerous habit. Use this tool to inspect structure and debug claims; do the actual verification in your backend with a battle-tested library.
The classic JWT vulnerabilities almost all stem from trusting the token too much. The alg: none attack tricks a verifier into accepting an unsigned token. The algorithm-confusion attack feeds an RS256 public key to a verifier expecting HS256, letting an attacker sign tokens with public information. Both are defeated by pinning the expected algorithm rather than trusting the header. We cover this and more in our write-up on signature verification best practices, and dig into auth design during a web application penetration test.
For the conceptual background on the APIs these tokens protect, our glossary entries on what an API is and what TLS is are a good starting point — JWTs ride inside HTTPS requests, and TLS is what keeps the bearer token from being read in transit.
How to use it
Paste your token into the input. The header and payload decode live as you type, and a claims table breaks the payload into individual fields. Time-based claims (exp, iat, nbf) are rendered as readable local dates, and an expiry banner tells you immediately whether the token is still valid by its exp claim. Use the copy buttons to grab the pretty-printed header or payload. Everything stays on your machine — close the tab and it is gone.
FAQs
Does this JWT decoder verify the signature?
No. This is a decode-only tool. It splits the token on the dots and base64url-decodes the header and payload so you can read them, but it never checks the signature against a key. Decoding tells you what a token claims; only signature verification tells you whether those claims are authentic. Always verify the signature server-side with the issuer's public key (or shared secret) before trusting any claim for authorization.
Is it safe to paste a JWT here?
The decoding happens entirely in your browser with the built-in atob function — the token is never sent to a server, logged, or stored. That said, a valid JWT is a bearer credential: anyone who holds it can act as that user until it expires. As a matter of good hygiene, avoid pasting live production tokens into any third-party tool, and prefer expired or test tokens when you just need to inspect structure.
Why can I read the payload without a secret?
Because a standard JWT is signed, not encrypted. The header and payload are merely base64url-encoded JSON — encoding is not encryption. Anyone can decode and read the claims. The signature only guarantees the token has not been tampered with; it does not hide the contents. If you need the payload to be confidential, use an encrypted token (JWE) instead of a signed one (JWS), and never put secrets like passwords in a JWT payload.
What do the exp, iat, and nbf claims mean?
They are registered time claims expressed as Unix timestamps (seconds since 1970). 'iat' is issued-at — when the token was created. 'exp' is the expiry — after this instant the token must be rejected. 'nbf' is not-before — the token is invalid until this time. This tool renders each as a human-readable local date so you can spot a token that is expired or not yet valid at a glance.
What algorithm should my JWTs use?
For most APIs, HS256 (HMAC with a strong shared secret) is fine when the same party issues and verifies. Use an asymmetric algorithm like RS256 or ES256 when verifiers should not hold the signing key — for example, third parties validating tokens from your identity provider. Critically, never accept the 'none' algorithm and always pin the expected algorithm during verification; libraries that trust the header's alg field have historically been the source of serious authentication bypasses.
Related tools
Related engineering reading
All postsAPI Security Best Practices (2026)
Auth, rate limiting, input validation, secrets, and the OWASP API Top 10.
Read postPreventing Prompt Injection in AI Apps (2026)
Prompt injection as the new injection class, trust boundaries for tools and retrieval, and mitigations.
Read postPreventing SQL Injection in Modern Web Apps (2026)
Parameterized queries, ORMs, least-privilege DB roles, and why concatenation still breaches apps.
Read post
Is your token-based auth actually safe?
We have seen production systems trust the JWT header's algorithm, skip expiry checks, and store tokens where any script can read them. A focused security review catches these before an attacker does. Talk to us about authentication design and web application penetration testing.
Or reach us directly: (770) 652-1282 · beltz@quantlabusa.dev