JWT Decoder
Paste a JSON Web Token to read its header and payload in clear text and view expiry, issued-at and not-before times as human dates — decoded locally, never sent to a server.
The signature is not verified — decoding only
Decoding a JWT only reveals its contents; it does not prove the token is authentic or untouched. A decoded token can be edited by anyone. Never make an access decision from a decoded token alone: verify the signature against the issuer's public key or secret on your server, and check the algorithm, issuer and audience.
Header (decoded)
Payload / claims (decoded)
Time-based claims
Expires at (exp)
Issued at (iat)
Not before (nbf)
Signature (raw)
The signature is shown exactly as received. This tool does not validate it.
Common registered claims
| iss | Issuer — who created and signed the token, typically your authentication server. |
| sub | Subject — the principal the token is about, usually the user identifier. |
| aud | Audience — the recipient or API the token is intended for. |
| exp | Expiration time — epoch seconds after which the token must be rejected. |
| nbf | Not before — epoch seconds before which the token must not be accepted. |
| iat | Issued at — epoch seconds when the token was created. |
| jti | JWT ID — a unique identifier for the token, useful for revocation lists. |
How to Decode a JWT
A JSON Web Token is nothing more than three base64url strings joined by dots. Decoding it turns the first two strings back into readable JSON so you can inspect the header and the claims without any special software. Follow these steps.
Paste the token. Copy the whole token — it is long — and paste it into the field. As an example, the token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE1MTYyNDI2MjJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c decodes to a header and a payload that are both readable JSON.
Read the header. The header states which algorithm signed the token and its type. In the example above it is {"alg":"HS256","typ":"JWT"}, meaning the issuer used an HMAC-SHA256 shared secret. If you see "alg":"none" or an algorithm you did not expect, treat the token with suspicion.
Inspect the payload. The payload carries the claims: registered fields such as sub, iat and exp, plus application fields such as name or role. In the example the subject is 1234567890, the name is Jane Doe and the role is admin, so this token describes a specific user and their permission level.
Check the timestamps. The claim iat 1516239022 corresponds to 18 January 2018 at 01:30:22 UTC, and exp 1516242622 is exactly one hour later. The tool prints both as local dates and marks the token expired or still valid at a glance, which is far safer than comparing large integers by eye.
Confirm the three-part structure. If the count of segments is not three, or a segment is not valid base64url, or the decoded text is not JSON, the tool reports a precise, localised error instead of guessing. Fix your copy and decode again.
Remember what decoding does not do. This page never checks the signature, the issuer or the audience. Use it to understand and debug a token, then verify it properly inside your own service before you trust any claim.
What Is a JWT, and Why Decoding Is Not Verifying?
A JSON Web Token, defined in RFC 7519, is a compact, URL-safe way to represent claims between two parties. It has three parts separated by dots. The header is a small JSON object describing the token, usually the signing algorithm (alg) and the type (typ). The payload is a JSON object of claims — statements about the user or the session. The signature is a cryptographic value derived from the first two parts. Each part is encoded with base64url, a variant of base64 that replaces + with - and / with _, and omits the = padding so the token can travel safely in URLs, HTTP headers and cookies. Base64url is an encoding, not encryption. Anyone holding the token can reverse it in a fraction of a second, which is precisely why a JWT must never contain secrets. The header and payload are readable by the client and by anyone who intercepts the token; only the signature depends on a key. That signature is what proves integrity: the issuer computes it over header.payload with a secret or private key, and the receiver recomputes and compares it. If a single character of the payload is changed, the signature no longer matches and a correctly implemented server rejects the token. The crucial distinction is therefore between decoding and verifying. Decoding, which this tool does, is simple parsing that requires no key and proves nothing. Verifying requires the issuer's key, confirms the signature, and normally also checks that the token has not expired, that the issuer (iss) and audience (aud) are the expected ones, and that the algorithm is one you allow. A common attack is to strip the signature and set alg to "none", or to swap RS256 for HS256 and trick a server into treating a public key as an HMAC secret. A decoder will happily show you such a tampered token; only a verifier rejects it. Use decoding to inspect and debug, and verification to grant access.
Common Applications
1. Debugging an authentication flow. You log in and get "401 Unauthorized" on every request. Decoding the access token reveals {"exp":1516242622}, and you notice the expiry is in 2018 — the server clock or the token lifetime is wrong. No key needed.
2. Reading the identity a token represents. A support engineer pastes a customer's token and sees {"sub":"1234567890","role":"admin","scope":"orders:read"} to understand which permissions the client believes it holds, without touching the production database.
3. Checking token lifetime during an incident. If tokens are meant to live one hour but a sample shows iat and exp only sixty seconds apart, the refresh logic or the configuration is misconfigured, and the decoder exposes that instantly.
4. Inspecting third-party identity tokens. OpenID Connect returns an id_token containing fields such as iss, aud and email. Decoding it shows which provider issued it and which client it is meant for, which is useful when wiring a new SSO integration.
5. Teaching and code review. When reviewing an authentication change, pasting a sample JWT into the decoder makes the difference between a token that carries only a user ID and one that carries a whole permission list immediately obvious to the whole team.
6. Auditing claims for privacy. Decoding reveals whether sensitive data such as an email address or an internal role leaked into the payload, because everything in the payload is visible to the client and to anyone who captures the token.
Common security pitfalls
The first pitfall is trusting the payload. Because base64url is reversible, a decoded claim such as "role":"admin" is only a statement, not a fact, until the signature is verified. The second is the "alg":"none" confusion: an attacker can rebuild the header without a signature, and a server that fails to pin the expected algorithm may accept it. The third is the RS256-to-HS256 downgrade, where a server is tricked into verifying an asymmetric token with the public key as an HMAC secret. The fourth is treating a token as a session: because a JWT is self-contained, it stays valid until exp even after logout, unless you add a jti revocation list or short lifetimes. Finally, never store a JWT in localStorage if an XSS bug is possible; an httpOnly, Secure cookie is safer. This decoder deliberately performs none of these checks, which is exactly why you must verify elsewhere.
JWT vs opaque session tokens
An opaque token is a random string whose meaning lives in a database; the server looks it up, so it can be revoked instantly and it leaks nothing by itself. A JWT is self-contained: the server can trust it by checking a signature without a lookup, which scales across microservices but makes revocation harder. That trade-off is the whole story. Use JWTs when many services must validate a token independently, when you need short-lived credentials, or when a third party must verify your token. Use opaque tokens when instant revocation, minimal token size or keeping all state server-side matters more. Many systems combine both: a short-lived JWT access token for speed plus an opaque refresh token stored and revocable in the database. Decoding a JWT makes its self-contained nature obvious, since every claim is right there in the string.
Registered vs private claims
RFC 7519 reserves seven claim names so that different systems agree on their meaning: iss, sub, aud, exp, nbf, iat and jti. Everything else is a private claim chosen by the issuer, such as role, scope, tenant or email. Registered claims should be treated by every receiver; private claims only make sense to the applications that define them. Two practical consequences follow. First, always check exp and aud even if your framework does it for you, because a token minted for one API should not be accepted by another. Second, keep private claims small and non-sensitive: a numeric user ID is fine, but a full profile or a password reset code does not belong in a token that any client can read.
Related Utilities
- JSON Formatter & Validator — Free JSON Beautifier
- Base64 Encoder & Decoder — Online Converter
- Password Generator — Strong Random Passwords
- URL Encoder & Decoder — Free Percent-Encoding Tool
- UUID Generator — Generate Random UUID v4 Online
- Remove Duplicate Lines — Online Line Remover
Guides
Frequently Asked Questions - FAQ
Is my token sent to a server?
No. The whole decoding happens in your browser with native JavaScript (atob and TextDecoder). The token never leaves your device, so it is safe to paste production tokens here for inspection.
Does this tool verify the signature?
No, and no client-side decoder can. It only reverses the base64url encoding of the header and payload. Verifying a signature requires the issuer's key and must be done on your server, where you also check the algorithm, expiry, issuer and audience.
Why are there three parts, and can a JWT have two?
A signed JWT (JWS) always has header, payload and signature. An unsecured token with alg "none" can end with an empty third segment, so you may see trailing dots. An encrypted token (JWE) has five parts. This decoder expects the standard three-part form.
Can I read a JWT without the secret key?
Yes. The header and payload are only base64url-encoded, not encrypted, so anyone can read them with no key at all. This is by design, and it is why the payload must never contain passwords, private keys or other secrets.
The tool says my segment is not valid JSON. What is wrong?
Most often the token was truncated when copied, a newline was inserted, or one segment was edited. Re-copy the complete token and decode again. If it still fails, the token may be encrypted (JWE) or use a non-standard encoding.
Last updated: