How to decode a JWT
- Paste your token into the box, or press Try an example to load a harmless sample token.
- Check the colours. The token is shown split into its header, payload and signature, each in its own colour, so you can see where each part begins.
- Read the header and payload as formatted JSON. Use the copy button beside either block to take the JSON with you.
- Look at the time claims. Expires (exp), Issued (iat) and Not before (nbf) are converted to readable dates, with a status badge: Not expired, Expired, Not valid yet or No expiry set.
Features
- Instant decoding as you paste, with no button to press.
- Header and payload as pretty-printed JSON, each with its own copy button.
- Readable dates for the exp, iat and nbf claims, plus a clear expiry status.
- Accepts a Bearer prefix, so you can paste an Authorization header value as it is.
- Warns about alg none, a token with no signature that should never be trusted.
- Clear error messages for a token with the wrong number of parts, invalid Base64URL, invalid JSON, or an encrypted five-part JWE.
- Unicode-safe, so names and claims in Urdu, Hindi or any other script display correctly.
Why use Fileora's JWT decoder
Access tokens, ID tokens and refresh tokens are credentials. Pasting them into a website that sends them to a server is a real risk, because anyone who holds a valid token can act as that user until it expires. Fileora decodes the token with JavaScript in your browser, so the token never leaves your device, and nothing about it is logged.
The tool is free, needs no sign-up and has no limits. It works on a phone as well as a laptop, which helps when you are checking a token from a mobile app or a support ticket.
How a JWT is built
A signed JWT is three pieces of text joined by dots: header.payload.signature. The header and payload are JSON objects encoded with Base64URL, a version of Base64 that is safe to put in URLs. That encoding is not encryption. Anyone who has the token can read every claim in it, which is exactly what this tool does.
The header names the signing algorithm in alg, for example HS256 (a shared secret) or RS256 (a private and public key pair). The payload carries the claims: sub for the user, iss for the issuer, aud for the intended audience, and the time claims exp, iat and nbf, which are counted in seconds since 1970.
The signature is what makes the token trustworthy. Your server recalculates it from the header and payload using its key, and rejects the token if the result doesn't match, if alg is not one it expects, or if exp has passed. Because anyone can create a token with any payload they like, always verify the signature on your server with the secret or public key before trusting a single claim. A decoder like this one is for reading and debugging, not for deciding who is logged in.
Two tips: never put passwords or other secrets in a payload, since it is readable by anyone, and keep expiry times short. When you need a long random signing secret, the password generator can create one, and the JSON formatter is handy for tidying a payload you are building by hand.