What Is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe string that encodes a JSON object and includes a cryptographic signature. It looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The three parts — separated by dots — are the Header, Payload, and Signature. Each is Base64URL-encoded JSON (or a cryptographic value).

The Three Parts Explained

1. Header — describes the token type and signing algorithm:

{"alg": "HS256", "typ": "JWT"}

2. Payload — contains the claims (data). Standard claims include sub (subject/user ID), iat (issued at), exp (expiration), and iss (issuer). Custom claims can hold anything:

{"sub": "user_123", "name": "Alice", "role": "admin", "exp": 1716239022}

3. Signature — created by signing the encoded header + payload with a secret key using the algorithm from the header. For HS256: HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)

How JWT Authentication Works

1. User logs in with username and password.
2. Server verifies credentials and generates a JWT signed with a secret key.
3. Server returns the JWT to the client.
4. Client stores the JWT (localStorage, sessionStorage, or httpOnly cookie).
5. On every API request, client sends the JWT in the Authorization: Bearer <token> header.
6. Server verifies the JWT signature — if valid, reads the claims without a database lookup.
7. Server uses the claims (user ID, role) to authorise the request.

Signed vs Encrypted JWTs

A standard JWT is signed (JWS) but not encrypted. The payload is merely Base64URL-encoded — anyone can decode it. The signature only proves the token has not been tampered with; it does not hide the content.

Never store sensitive data (passwords, credit card numbers, personal data that must be private) in a JWT payload unless using JWE (JSON Web Encryption). For most authentication use cases, storing user ID and role is sufficient and safe because these are not confidential values.

JWT Expiration and Refresh Tokens

JWTs contain an exp (expiration) claim. Once expired, the server rejects the token. Typical access token lifetimes are 15 minutes to 1 hour. For longer sessions, a refresh token (stored in an httpOnly cookie) is exchanged for a new access token when the current one expires. This limits the damage if an access token is stolen.

How to Decode a JWT

Use the ToolsBox JWT Decoder. Paste any JWT and instantly see the decoded Header and Payload as formatted JSON. Remember: decoding only reads the data — it does not verify the signature. Signature verification requires the secret key and must be done server-side.

Frequently Asked Questions

What does JWT stand for?

JWT stands for JSON Web Token — an open standard (RFC 7519) for transmitting claims as a signed JSON object. The three Base64URL-encoded parts are Header, Payload, and Signature.

What are the three parts of a JWT?

Header (algorithm and type), Payload (claims — user ID, expiration, custom data), and Signature (cryptographic proof that the token was not tampered with). Each part is Base64URL-encoded and separated by dots.

Is a JWT encrypted?

No. A standard JWT (JWS) is signed but the payload is only Base64URL-encoded — anyone can decode it. Do not store passwords or sensitive personal data in a JWT payload. Use JWE (JSON Web Encryption) if the payload content must be private.

What is the difference between authentication and authorisation with JWTs?

Authentication confirms who the user is (login). The server issues a JWT after successful authentication. Authorisation uses the JWT — the server verifies the signature and reads the claims to decide what the authenticated user is allowed to access, without a database query.