What Is JWT? JSON Web Tokens Explained with a Login Example

JWT meaning in simple words

JWT means JSON Web Token. It is a short text in a standard format, signed by the system that issued it, that carries a few claims. A claim is one small fact, such as who the token is about or when it expires. The receiver can check who issued the token and that nobody changed it.

Think of a certificate with an official stamp from a faculty in Egypt. Anyone can read it, but only the faculty can stamp it. An employer looks at the stamp instead of calling the faculty. A JWT works the same way, with one improvement: its stamp is calculated from the text, so if one letter changes, the stamp no longer matches.

On websites, a JWT is most often used after sign in: the server checks who you are once, and your browser then shows the token instead of your password.

The three parts of a JWT: header, payload, signature

A JWT is one line of text with two dots, which split it into three parts. The token below is an invented example for teaching. It is not a real token, and it is shown on three lines only to make it easy to read.

EXAMPLE ONLY, NOT A REAL TOKEN

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9
.eyJpc3MiOiJleGFtcGxlIiwic3ViIjoidTQ4MjEiLCJleHAiOjE3NjcyMjU2MDB9
.[the signature: a long text in the same encoding]

Header, decoded:
{"alg":"RS256","typ":"JWT"}

Payload, decoded:
{"iss":"example","sub":"u4821","exp":1767225600}

The parts are written in Base64URL, an encoding that turns data into characters that are safe inside a URL or a header. Encoding is not encryption: anyone can decode the first two parts with no key.

• Header: the type of the token and the signing method, here RS256.
• Payload: the claims. This is the part your application reads.
• Signature: a value calculated from the header, the payload and a key. It is the stamp.

The standard defines short names for common claims:

Times are written as a count of seconds since the start of 1970. In the example, exp is the first second of 2026 in UTC time.

How the signature is checked with RS256

RS256 is a common signing method. It uses two keys that belong together. The private key stays with the issuer and signs tokens. The public key can be given to anyone and only checks them.

In the stamp example, the private key is the stamp itself, locked in a drawer. The public key is a published sample of its print: with it you can check a stamp, but you cannot make one.

1. The issuer signs the header and the payload with its private key.
2. The receiver tests the signature with the public key that the issuer publishes. If one character was changed, the test fails and the token is refused.
3. The receiver then checks the claims: exp must be in the future, and iss must be the issuer it expects.

Only after both checks can your code trust what the payload says. Do not write the signature test yourself: every common language has well tested JWT libraries for it.

With other methods, such as HS256, one shared secret both signs and checks, so everyone who can check a token can also create one.

What a JWT is not: it is signed, not encrypted

The signature shows the receiver whether the content was changed. It does not hide the content. Whoever holds the token can decode the payload in seconds.

• Never put a password, a card number or any other secret in a JWT.
• Keep personal data out of it. A user ID is usually enough.
• Send tokens only over HTTPS. A stolen token works for the thief until it expires, like a cinema ticket that lets in whoever holds it.

JWT compared with a classic session ID

A classic session ID is a random string. The server stores it next to the user's data and looks it up on every request. A JWT turns this around: the facts travel inside the token, and the server checks the token instead of looking anything up.

Neither one wins everywhere. A session ID is simple and easy to cancel. A JWT helps when several servers or websites must trust the same sign in without sharing a database.

Common JWT mistakes

Most JWT problems come from a few mistakes:

• Accepting an unverified token. Decoding is not checking. Anyone can write a payload that says they are the admin.
• Trusting the header. The header names the signing method, but an attacker can write any header. Accept only the method you expect.
• Not checking expiry. A token with a valid signature can still be too old.
• Long lifetimes. A token that lives for months gives a thief months of access. Prefer short lifetimes.
• Careless storage. Keep tokens out of URLs and logs, and away from scripts that do not need them.

How Gammal Tech uses signed tokens

Gammal Tech, an Egyptian platform that gives a website ready backend services through one script, issues signed JSON Web Tokens with RS256. You meet them in two places:

• Sign in. After GammalTech.login(), the SDK stores the session token for you, so you rarely touch it. A new session token is issued at every login. The token does not reveal the user's email, phone number or identity: it only proves that the user is genuinely signed in.
• Payments. A payment returns a short lived payment_token. You verify it at https://api.gammal.tech/sdk/pay/link/verify.php before you deliver anything (see what is a webhook).

A server can check any Gammal Tech token in two ways: send it in a POST to https://api.gammal.tech/token/verify.php with the JSON body {"token": "…"}, or fetch the public key from https://api.gammal.tech/token/public-key.php and test the signature itself. The first way is shorter, in any server language. Here it is in JavaScript:

// Runs on your server: is this Gammal Tech token genuine?
const url = 'https://api.gammal.tech/token/verify.php';

async function checkToken(token) {
  try {
    const response = await fetch(url, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ token: token })
    });
    return await response.json(); // the reply, as an object
  } catch (error) {
    return null; // no reply: treat the token as not verified
  }
}

For the fields of the reply, use the live guide as your reference. Do not guess claim names.

Login example: a course site in Alexandria

A small site in Alexandria sells recorded lessons. A paid lesson must open only for a visitor who is really signed in, and the page alone cannot decide that, because anything a browser sends can be faked. So the decision is made on the server:

1. The student signs in with GammalTech.login(). The site stores no password.
2. When the student opens a paid lesson, the page sends the session token to the site's own server. The SDK has a GammalTech.getToken method, and the live guide shows its exact use.
3. The server checks the token with the code above. If the check passes, it sends the lesson. If not, it asks the visitor to sign in.

The token proves one thing: this visitor is genuinely signed in. Whether the visitor has paid is a separate check against the site's own records of verified payments.

Common questions about JWT