JSON guide · 2 min read
How to Decode a JWT Safely
Decode JWT headers and payloads locally, inspect standard claims and understand why readable token contents are not proof of authenticity.
A typical signed JWT has three dot-separated segments
A compact signed JWT commonly contains a header, payload and signature. The first two segments are Base64URL-encoded JSON. Encoding is not encryption, so a person holding the token can normally read those claims.
header.payload.signatureDecode the header as metadata, not authority
The header commonly declares token type and signing algorithm. Reading alg is useful during inspection, but a verifier must enforce allowed algorithms rather than trusting what an untrusted token declares.
{
"alg": "RS256",
"typ": "JWT"
}Inspect standard payload claims
Claims such as exp, nbf, iat, iss, aud and sub describe expiration, validity windows, issuer, audience and subject. Decoding makes them readable; it does not prove a trusted issuer produced them.
- exp: expiration time.
- nbf: not-before time.
- iat: issued-at time.
- iss: issuer.
- aud: intended audience.
- sub: subject identifier.
Verification is the security boundary
A secure application verifies the signature with the expected key and algorithm, then checks issuer, audience, expiration and other required claims. A manually edited token remains decodable, which is exactly why decoding alone cannot establish trust.
Handle time claims with the correct units
JWT NumericDate values use seconds since the Unix epoch. Front-end APIs often use milliseconds, so a factor-of-1000 error can make expiration checks look completely wrong. Production verifiers may also allow limited clock skew between systems.
Treat bearer tokens as secrets
A bearer token can grant access to whoever possesses it. Do not paste production tokens into tickets, public chats or remote decoding services. Local decoding reduces one transfer risk, but clipboard history, screenshots and browser extensions remain separate considerations.
Use decoding for diagnostics, not authorization
Decode tokens to inspect claims or diagnose expiration. Use a trusted JWT library for cryptographic verification and authorization decisions in application code.
Primary sources
References and specifications
- RFC 7519 — JSON Web Token (JWT)
The IETF standard defining JWT claims and token structure.
- RFC 8725 — JSON Web Token Best Current Practices
Security guidance for validating and using JWTs safely.
Common questions
Frequently asked questions
Is JWT payload data encrypted?
Usually not for a signed JWT. The payload is encoded and readable; encryption is a separate design such as JWE.
Can a decoded JWT be trusted?
No. Trust requires signature verification plus validation of issuer, audience, expiration and other required claims.
Is it safe to paste a production JWT into a decoder?
Prefer local inspection and use redacted or synthetic tokens when sharing examples. Bearer tokens should be handled as secrets.