DevCoreTools

JWT Guide

JWT Guide for decoding, verification, claims, and signatures

JWTs are commonly used in API authentication and authorization. This guide helps developers inspect token structure, understand claims, verify signatures, debug expiration issues, and choose the right DevCoreTools utility.

Which JWT tool should I use?

Start with the question you need answered. These tools inspect JWTs, timestamps, encodings, signatures, and related security values locally in your browser.

Decode token header and payloadJWT DecoderVerify token signatureJWT VerifierInspect Base64URL piecesBase64 Encoder/DecoderConvert exp, iat, and nbf timestampsUnix Timestamp ConverterUnderstand HMAC signingHMAC GeneratorCompare hashing conceptsHash Generator

What is a JWT?

JWT stands for JSON Web Token. It is a compact token format used to transfer claims between systems, especially in API authentication and authorization flows.

A JWT can carry identity, issuer, audience, timing, role, and permission details. The token is useful only when the receiving system verifies the signature and checks the trust rules it expects.

JWT structure

A compact JWT usually has three dot-separated parts: a header, a payload, and a signature.

JWT shape

header.payload.signature
  • The header describes token and signing metadata, such as typ, alg, and sometimes kid.
  • The payload contains claims about the subject, issuer, audience, timing, and permissions.
  • The signature is used to detect tampering when the token is verified with the correct key and rules.

Base64URL encoding

JWT headers and payloads are usually Base64URL-encoded JSON. Base64URL is an encoding, not encryption. Anyone with the token can often decode and read those sections.

Use the Base64 Encoder/Decoder when you need to inspect a segment. The key point: a readable payload does not mean a trusted payload.

Common JWT claims

Claims are payload fields. Some are standardized, while others are application-specific. Timing claims such as exp, iat, and nbf are commonly Unix timestamps in seconds.

Claim quick reference

exp
Expiration time. Convert it with the Unix Timestamp Converter.
iat
Issued-at time. Useful for debugging token age and clock skew.
nbf
Not-before time. The token should not be accepted before this moment.
iss
Issuer. The system that created or authorized the token.
aud
Audience. The service or application the token is intended for.
sub
Subject. Often a user, account, client, or service identifier.
scope
Space-delimited permissions, commonly used by OAuth-style APIs.
roles
Application-specific roles or groups.
jti
JWT ID. A unique identifier that can help with replay detection or revocation lists.

Decode vs verify

Decode means read the header and payload. Verify means check the signature and expected trust rules. Use the JWT Decoder for inspection and the JWT Verifier when you need a signature and claim check.

Decoding is not verification. A token can decode correctly and still be invalid, expired, tampered with, signed by the wrong key, or meant for another audience.

HS256 vs RS256

HS256 uses a shared secret with HMAC. The same secret signs and verifies the token, so it is common for trusted internal systems where secret distribution is tightly controlled.

RS256 uses a private key to sign and a public key to verify. It is common when many services need to verify tokens without sharing the signing key. The HMAC Generator is useful for understanding shared-secret signing concepts.

JWT expiration and timestamps

The exp, iat, and nbf claims are commonly Unix timestamps in seconds. Developers often confuse seconds with milliseconds, or misread local time versus UTC during debugging.

Clock skew between systems can make a valid-looking token fail. Expired tokens can still be decoded, but they should not be accepted. Convert timing claims with the Unix Timestamp Converter.

JWK and JWKS basics

A JWK is a JSON representation of a key. A JWKS is a set of keys. JWT headers may include kid, a key ID that helps a verifier choose the matching public key from a JWKS endpoint.

Use the JWK / JWKS Inspector when you need to review key fields and understand which key a JWT header is asking a verifier to use.

Common JWT debugging mistakes

Trust mistakes

  • Treating decoded payload as trusted.
  • Ignoring signature verification.
  • Accepting alg: none.
  • Not checking issuer.
  • Not checking audience.

Encoding and key mistakes

  • Confusing Base64URL encoding with encryption.
  • Using the wrong secret or public key.
  • Hashing a value when a signature check is required.

Timing and workflow mistakes

  • Mixing seconds and milliseconds for timestamps.
  • Ignoring expiration.
  • Assuming an expired token is valid because it decodes correctly.
  • Copying sensitive production tokens into random websites.

Security notes

JWTs can contain sensitive user, session, identity, or authorization data. Prefer local, browser-based tools for inspection when possible, and avoid pasting production access tokens, private keys, secrets, passwords, or customer data into untrusted tools.

DevCoreTools JWT utilities are designed for local browser-based inspection. User-entered JWTs are not sent anywhere by the Learn guide.

JWT Guide FAQ

Is decoding a JWT the same as verifying it?

No. Decoding reads the header and payload. Verification checks the signature and expected trust rules.

Are JWT payloads encrypted?

Usually no. Standard signed JWT payloads are encoded, not encrypted, so avoid putting secrets in them.

What is the difference between HS256 and RS256?

HS256 uses one shared secret for signing and verification. RS256 signs with a private key and verifies with a public key.

Why does my JWT say expired?

The exp claim is in the past, the timestamp unit was misread, or clock skew is affecting validation.

What is kid in a JWT header?

kid is a key ID. Verifiers use it to pick the matching key from a known key set.

What is the difference between JWK and JWKS?

A JWK describes one key as JSON. A JWKS is a JSON set containing one or more keys.

Can I safely paste JWTs into online tools?

Use local, trusted tools where possible. Avoid pasting production tokens, secrets, private keys, or customer data into tools you do not control.