Skip to content

JWT Decoder

Inspect any JWT in your browser. Nothing is sent to a server.

Runs locally in your browser

Decoding happens in your browser. Nothing is sent to a server.

How it works

Anatomy of a JWT

A JWT is three base64url-encoded segments separated by dots. The decoder above splits them for you:

  • Header: algorithm (alg), token type (typ), and sometimes a key id (kid) to tell the server which key signed this token.
  • Payload: the claims. Standard ones include iss (issuer), sub (subject), aud (audience), exp (expiry, UNIX seconds), iat (issued at), nbf (not before).
  • Signature: used to verify the token was issued by the holder of the key. This decoder does not verify signatures, decoding is a separate concern from validating.

Security note

Decoding a JWT is trivial, the payload is not encrypted. Don't put secrets in a JWT payload. Always verify the signature server-side before trusting any claim.

Frequently asked questions

Does this decoder send my JWT to a server?

No. Decoding happens entirely in your browser using base64url decoding. Nothing is transmitted.

Can a JWT be decoded without the secret?

Yes. JWT payloads are base64url-encoded, not encrypted. Anyone with the token can read its header and payload. The signature requires the secret to verify, not to read.

What do iat and exp mean?

`iat` is the issued-at timestamp (UNIX seconds). `exp` is the expiration timestamp. This decoder shows them in ISO format plus a relative indicator.

Why should I never put secrets in a JWT?

The payload is not encrypted, just encoded. Anyone who intercepts the token can read every claim. If you need confidentiality, encrypt the payload (JWE) or use opaque tokens.

Tools are ported from DevOps Daily under the MIT license.View original

More tools

CIDR Subnet Calculator

Parse CIDR blocks, compute ranges, split into smaller subnets, and check whether an IP lives inside a network.

Open tool