JWT Decoder
Paste a JSON Web Token below — the header and payload are decoded live as you type.
Decoded on your device — the token is never sent anywhere. The signature is not verified.
How it works
- Paste your JWT into the input box. A valid token has three dot-separated parts and usually starts with eyJ.
- Read the decoded header and payload, shown as formatted JSON. Timestamp claims like exp, iat and nbf are translated into human-readable dates, and expired tokens are flagged.
- Click Copy under either panel to put the decoded JSON on your clipboard.
Frequently asked questions
- Does this tool verify the token’s signature?
- No. Decoding only reads the header and payload, which are plain Base64url-encoded JSON — no secret or public key is needed for that. Verifying the signature requires the signing key and should be done by the server that issued or consumes the token. Never trust a token’s claims just because they decode cleanly.
- Is it safe to paste a real token here?
- The token is decoded entirely in your browser with JavaScript — nothing is sent to any server, and nothing is stored. Still, treat production tokens like passwords: they can grant access to accounts and APIs, so avoid pasting live credentials into any tool on a shared or untrusted machine.
- What are the three parts of a JWT?
- A JWT is three Base64url strings joined by dots. The header records the token type and signing algorithm, the payload carries the claims — user identity, roles, timestamps — and the signature is a cryptographic checksum of the first two parts. This tool decodes the header and payload; the signature is binary and only meaningful to a verifier holding the key.
- What do the exp, iat and nbf claims mean?
- They are Unix timestamps in seconds. iat (issued at) records when the token was created, nbf (not before) marks the earliest moment it becomes valid, and exp (expiration) is the moment it stops being accepted. This tool converts all three to local dates and shows whether the token has already expired.
- Why won’t my token decode?
- The usual culprits are an incomplete paste — tokens are long and easy to truncate — extra whitespace or quotes copied along with the token, or a prefix like “Bearer ” left in from an Authorization header. Check that the input has exactly three dot-separated parts; opaque session tokens that are not JWTs at all will also fail, since they contain no JSON to decode.
About this tool
JSON Web Tokens are everywhere in modern authentication — session cookies, OAuth access tokens, API credentials — but on the wire they look like an opaque wall of characters. This decoder turns that wall back into something readable. Paste a token and the header and payload appear instantly as formatted JSON, with timestamp claims such as exp, iat and nbf converted into local dates and a clear flag when a token has already expired.
The reason this works without any secret key is that a JWT is not encrypted — it is only encoded. The header and payload are plain JSON run through Base64url, a transformation anyone can reverse; only the third part, the signature, involves cryptography, and it protects integrity rather than confidentiality. The decoding here happens entirely in your browser with a few lines of JavaScript: no request is made, nothing is logged and the page works offline. Even so, production tokens are live credentials, so handle them with the same care as passwords.
The everyday use case is debugging. An API rejects a request with 401 and you need to know why: paste the token and immediately see whether it expired an hour ago, carries the wrong audience or scope, or was issued by a different environment than you expected. It is equally useful when integrating a third-party identity provider — decoding a real token is the fastest way to learn exactly which claims it sends and what they are named — and when writing tests that assert on token contents.
Two practical notes. First, decoding is not verification: anyone can mint a token with any claims, and only a signature check against the issuer’s key proves authenticity, so servers must always verify before trusting. Second, this asymmetry is a design lesson for your own APIs — never put secrets in a JWT payload, because every holder of the token can read it as easily as this page does.