JWT Decoder
JSON Web Tokens (JWT) are a compact, URL-safe way to represent claims between parties. They consist of three parts:
- Header: Contains the token type and signing algorithm
- Payload: Contains the claims (data)
- Signature: Used to verify the token wasn't tampered with
About the JWT Decoder
The JWT Decoder parses a JSON Web Token and reveals its contents in a readable form. A JWT is made of three Base64URL-encoded segments joined by dots — the header, the payload, and the signature. The decoder splits the token, Base64URL-decodes the first two parts, and displays the resulting JSON so you can inspect exactly what claims a token is carrying without writing any code.
The header typically declares the signing algorithm (such as HS256 or RS256) and token type, while the payload holds the claims — standard ones like iss (issuer), sub (subject), aud (audience), exp (expiration), and iat (issued-at), plus any custom application data. Reading these is invaluable when debugging authentication, since you can confirm a token's audience matches your API, check whether it has expired, or verify which user and scopes it represents. The decoder makes the human-readable timestamps and claim values immediately visible.
Common use cases include troubleshooting OAuth 2.0 and OpenID Connect flows, inspecting access and ID tokens from identity providers like Auth0, Okta, or Cognito, debugging session issues, and confirming that a backend is emitting the claims a client expects. Because decoding is the same Base64 unpacking used elsewhere, this complements a JSON Formatter for prettifying the decoded payload and a Hash Generator when reasoning about signing inputs.
A critical tip: decoding is not verifying. The signature is what proves a token is authentic and untampered, and verifying it requires the secret or public key — decoding alone reveals the claims but does not confirm they are trustworthy. Never trust a decoded payload in production without validating the signature server-side, and remember that anyone can read a JWT's payload, so it should never contain passwords or other secrets.
Frequently asked questions
- Does decoding a JWT verify that it is valid?
- No. Decoding only reveals the header and payload. Verifying authenticity requires checking the signature with the secret or public key, which proves the token was not tampered with and was issued by a trusted party.
- What are the three parts of a JWT?
- A JWT has a header (algorithm and type), a payload (the claims), and a signature, each Base64URL-encoded and joined by dots. The decoder shows the first two parts as readable JSON.
- Can anyone read the contents of my JWT?
- Yes. The payload is only Base64-encoded, not encrypted, so anyone with the token can read it. Never store passwords or sensitive secrets in a JWT payload.
- How do I tell if a token is expired?
- Check the exp claim, a Unix timestamp marking expiration, and the iat (issued-at) claim. If the current time is past exp, the token has expired and should be rejected.
- What do common claims like iss, sub, and aud mean?
- iss is the issuer that created the token, sub is the subject (usually the user ID), and aud is the intended audience (the API or service the token is meant for). They are used to validate that a token belongs to your application.
Format, validate, and minify JSON data
Encode and decode Base64
Convert between Unix timestamps and dates
Encode and decode URL-encoded strings
Parse URL into components
Generate QR codes from URLs or text