A JSON Web Token, or JWT, is a compact format for carrying claims between systems. JWTs are common in authentication and API authorization. Their contents are often readable, but their security depends on signature verification and careful server-side validation.

The QuickToolsBox JWT Decoder lets you inspect the header and payload locally in your browser. Do not paste a production token into screenshots, support chats, or public issue trackers.

The three JWT sections

A commonly used signed JWT has three dot-separated parts:

header.payload.signature

The header and payload are JSON encoded with Base64URL. The signature is calculated from the encoded header and payload using an algorithm and key.

The header may identify the algorithm and key ID. The payload contains claims. The signature allows a verifier with the correct key to detect unauthorized changes.

Decoding is not verification

Anyone can create or modify the first two sections. A decoder can show what a token claims, but it cannot establish that a trusted issuer created it unless it also verifies the signature with an approved key and validates the expected algorithm.

Never grant access because a decoded payload contains "admin": true. Authorization decisions belong on the server after full verification.

Common registered claims

  • iss: the issuer that created the token
  • sub: the subject represented by the token
  • aud: the intended audience
  • exp: the expiration time
  • nbf: the time before which the token should not be accepted
  • iat: the time the token was issued
  • jti: a token identifier

Time-based JWT claims normally use NumericDate values, expressed as seconds since the Unix epoch. A timestamp converter can help you inspect them.

A safe inspection workflow

  1. Use a development or redacted token whenever possible.
  2. Decode the header and payload.
  3. Check the stated issuer, audience, subject, and expiry.
  4. Treat all decoded values as untrusted until verification succeeds.
  5. Verify the signature on the server with a trusted library and key source.
  6. Enforce application-specific authorization separately.

What proper verification should check

A production verifier should restrict accepted algorithms rather than trusting any algorithm named by the token. It should use a key associated with the expected issuer, validate the signature, confirm the audience, enforce expiry and not-before claims, and apply an appropriate clock-skew tolerance.

Key rotation also matters. Systems commonly use a key ID to select one key from an issuer's published set. The key source itself must be obtained and cached securely.

Common JWT mistakes

Logging complete tokens

Access tokens are credentials. Application logs, analytics events, error reports, and URLs can expose them to more systems and people than intended.

Putting sensitive data in the payload

Signed JWT payloads are normally encoded, not encrypted. A user who receives the token can decode it. Avoid storing passwords, private personal details, or secrets in ordinary JWT claims.

Ignoring the audience

A token intended for one service should not automatically be accepted by another. Audience validation helps prevent this confusion.

Using JWTs in query strings

URLs may be recorded in browser history, proxies, server logs, and referrer headers. Authorization headers or secure cookies are normally safer transport choices, depending on the architecture.

Frequently asked questions

Can I edit a decoded JWT?

You can change the text, but the existing signature will no longer match. A secure server will reject the modified token.

Does HTTPS make JWT validation unnecessary?

No. HTTPS protects data in transit. JWT validation determines whether the token is authentic and appropriate for the current request.

Is every three-part string a valid JWT?

No. Each part must follow the relevant encoding and structure, and a signed token must pass cryptographic and claim validation before it can be trusted.