What is JWT? A Beginner's Guide to JSON Web Tokens

JSON Web Tokens (JWT) have become the standard for modern web authentication. If you've ever logged into a single-page app, used a REST API, or implemented OAuth 2.0, you've likely encountered JWTs. This beginner-friendly guide explains what JWTs are, how they work, and how to decode and inspect them using a free JWT decoder.

What is a JWT?

A JSON Web Token (pronounced "jot") is a compact, URL-safe token format for transmitting claims between parties. It's defined by the open standard RFC 7519. JWTs are digitally signed, so the receiving party can verify the sender's identity and ensure the content hasn't been tampered with.

A JWT looks like three base64-encoded strings separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The three parts are the header, payload, and signature.

The Three Parts of a JWT

1. Header

The header contains metadata about the token: the signing algorithm (typically HS256 for HMAC-SHA256 or RS256 for RSA-SHA256) and the token type (JWT). Decoded, it looks like:

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

2. Payload (Claims)

The payload contains the claims — statements about the user and additional metadata. There are three types of claims:

• Registered claims: Standardized, optional claims like iss (issuer), sub (subject), aud (audience), exp (expiration time), iat (issued at), and nbf (not before)
• Public claims: Custom claims defined by the token creator, like name, email, or role
• Private claims: Claims agreed upon between parties for specific use

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622,
  "role": "admin"
}

3. Signature

The signature is created by taking the encoded header and payload, concatenating them with a dot, and signing the result with a secret key (HMAC) or a private key (RSA/ECDSA). The signature ensures the token hasn't been altered. Without the secret key, an attacker cannot forge a valid signature.

How Does JWT Authentication Work?

The typical JWT authentication flow works like this:

1. The user logs in with their credentials (username/password)
2. The server verifies the credentials and creates a JWT containing the user's identity and expiration time
3. The server signs the JWT and sends it back to the client
4. The client stores the JWT (usually in localStorage or an HTTP-only cookie)
5. For every subsequent API request, the client includes the JWT in the Authorization: Bearer <token> header
6. The server verifies the signature and expiration, extracts the user identity, and processes the request

Why Use JWTs?

• Stateless: The server doesn't need to store session data — all information is in the token itself
• Scalable: Since there's no server-side session, JWTs work perfectly in distributed systems and microservices
• Cross-domain: JWTs work across different domains and origins
• Mobile-friendly: Unlike cookie-based sessions, JWTs work natively with mobile apps
• Standardized: Libraries exist for virtually every programming language

How to Decode a JWT Online

Using a JWT decoder lets you inspect the contents of any JWT token instantly. Paste your JWT into the decoder and it will display:

• The decoded header (algorithm, token type)
• The decoded payload (all claims with human-readable timestamps)
• Whether the signature is valid (when you provide the secret key)
• Expiration status and remaining time

Our JWT decoder runs entirely in your browser — tokens are never sent to any server, keeping your user data safe.

JWT Security Best Practices

• Always use HTTPS: Tokens should never travel over unencrypted connections
• Set short expiration times: 15-60 minutes is standard; use refresh tokens for longer sessions
• Store tokens securely: Use HTTP-only cookies or secure storage mechanisms, never in plain localStorage for sensitive apps
• Validate the signature: Always verify the JWT signature on the server — never trust an unverified token
• Use strong secrets: Use a cryptographically random, sufficiently long secret key for HMAC algorithms
• Validate all claims: Check exp, nbf, iss, and aud on every request

JWT vs Sessions: Which Should You Use?

JWTs are excellent for API authentication, mobile apps, single-page applications, and microservice architectures. Traditional session-based authentication (with server-side session storage) may be simpler for server-rendered web apps that don't need cross-domain capabilities. Consider your specific needs — many modern applications use a combination of both.

Try our free JWT decoder to inspect your tokens. Also check out the Base64 encoder/decoder and JSON formatter for working with the individual parts of a JWT.