JWT Decoder - JSON Web Tokens

A JSON Web Token is a credential. This app decodes one, explains what it says, and checks its signature — entirely on your device, with no network access of its own. DECODE ANYTHING TOKEN-SHAPED Paste a token, or send one here from another app: select it in a log, a curl command, an Authorization header or a JSON response, then use Share or the Decode JWT item in the text menu. The token is pulled out of the text around it. Signed tokens (JWS) and encrypted ones (JWE) are both recognised. A JWE's claims cannot be read without the recipient's private key, so the app says so and shows what the protected header does reveal, instead of calling a valid token broken. When a token is damaged you still get what could be read: a truncated payload does not stop the header naming the algorithm and the key id. READ THE CLAIMS, NOT THE BASE64 Every registered claim is named and explained: issuer, subject, audience, expiry, not-before, issued-at, token id. Time claims show as a real date plus how far off — "expired 4 hours ago", "in 12 minutes" — in local time, UTC or raw seconds. Audience works whether it is a single string or a list. Around ninety claim names are recognised, including the OpenID Connect set and the vendor ones from Microsoft Entra, Firebase, AWS Cognito, Auth0 and Keycloak, so you can tell which system minted the token. CHECK THE SIGNATURE • HS256, HS384, HS512 against a shared secret — as text, base64, base64url or hex, which you choose rather than the app guessing • RS256/384/512, PS256/384/512, ES256/384/512 and ES256K against a public key • Keys accepted as a PEM, an X.509 certificate, a JWK, or an entire jwks.json — in which case the token's own key id picks the right entry The verdict is never just yes or no. "Does not match", "wrong kind of key", "wrong curve" and "this algorithm cannot be checked here" are four different answers, and you get the true one. A signature that verifies but is DER-encoded rather than the raw form JOSE wants is reported as exactly that: valid, and still going to be rejected elsewhere. KNOW WHAT IS WRONG WITH IT Thirty-five findings, each explained in a sentence rather than named in jargon: • "alg" set to none, so anyone can mint the token • an algorithm name whose capitalisation does not match any registered one • a key embedded in the header, or a header pointing at a remote key • a "crit" extension a verifier is required to understand and does not • "nbf" at or after "exp", so there is no moment the token is ever valid • "exp" emitted in milliseconds — or microseconds, or nanoseconds • the same claim appearing twice, which different libraries resolve differently • no audience, so nothing binds the token to the service receiving it • an ECDSA signature of the wrong length for its curve • and the one a lot of people need to hear: the payload is signed, not encrypted. Anyone holding the token can read every claim in it. BUILT FOR SOMETHING YOU DO NOT TRUST No token, key or secret is ever transmitted, and keys and secrets are never written to storage at all — they exist only while the screen is open. Recent tokens are kept on the device so you can return to them. The list shows a masked token and asks before revealing one; the store is capped and clearable, and it is excluded from Android's cloud backup and device-to-device transfer, so a stored token never leaves the phone. Switching the feature off deletes what is already there. ALSO • Light and dark, following your system setting • Ten languages • Syntax-coloured payload and header, numbers shown exactly as written • A configurable clock-skew allowance, so the verdict matches what a server with a slightly different clock would decide • Nested tokens: if the payload is itself a JWT, open it