JWT decoder

Paste a token and its header and payload appear as formatted JSON. A Bearer prefix copied from an Authorization header is fine; it's ignored. Show the steps explains each standard claim, turns the dates into UTC, and says whether the token has expired.

The decoding happens in your browser. A token is often a working password for whatever issued it, so this page never sends it anywhere.

A JSON Web Token is three parts joined by dots. The first is the header, which says how the token is signed. The second is the payload, the claims the token makes about someone. The third is the signature. The first two are JSON encoded with base64url, which is Base64 with - and _ in place of + and /, and the padding left off.

Base64url isn't encryption. Anyone holding a token can read its payload, which is exactly what this page does, so a JWT shouldn't carry anything secret. The signature stops it being changed, not read.

RFC 7519, the standard that defines JWTs, registers seven claim names. iss is who issued the token, sub is who it's about, and aud is who it's meant for. exp is when it expires, nbf the time before which it mustn't be accepted, and iat when it was issued. jti is a unique ID for the token.

The three times are NumericDates: the number of seconds since midnight UTC on 1 January 1970. 4102444800, for instance, is the first second of 2100. Anything else in the payload, like a name or a role, is up to whoever made the token.

Checking a signature needs the secret it was signed with, or the issuer's public key, and this page deliberately doesn't ask for either. So a token decoded here might have been made up: decoding shows what it says, not who said it. A header with alg set to none means the token isn't signed at all, and the steps point that out.

The standard suggests saying JWT the same way as the English word jot. It was published in May 2015.