What does JWT stand for?

JWT stands for JSON Web Token, a compact token format for securely transmitting claims between two parties as a JSON object.

By default, no. A standard JWT is signed and Base64URL-encoded, which makes it tamper-evident but not confidential — anyone can decode and read the payload. Encrypted variants (JWE) exist but are less common.

Can a JWT be revoked before it expires?

Not natively. Because verification doesn't require a server lookup, revoking a specific JWT before its expiry requires extra infrastructure like a token denylist or short expiry windows.

What is the difference between a JWT and a session cookie?

A traditional session cookie references server-side state that must be looked up on each request. A JWT is self-contained, so the server can verify it without a lookup, at the cost of harder revocation.

What should not go in a JWT payload?

Sensitive data such as passwords, secrets, or private personal information should never be placed in the payload, since it is readable by anyone who has the token.

What is a bearer token?

A bearer token is any token, including a JWT, that grants access to whoever presents it, typically sent in an HTTP Authorization: Bearer header.

Web

JSON Web Token (JWT)

IntermediateConcept2.1K learners

A JSON Web Token (JWT) is a compact, URL-safe, digitally signed token format used to represent claims — such as a user's identity or permissions — that can be verified and trusted between two parties without a database lookup.

#JSONWebToken #JWT #Web#Concept#Intermediate#OAuth #Authentication #SessionManagement #SingleSignOn #WebDevelopment#Glossary#SkillVeris

Definition

Overview

A JWT is made up of three Base64URL-encoded segments separated by dots: a header (specifying the signing algorithm and token type), a payload (the actual claims, such as user ID, issued-at time, expiry, and custom data), and a signature (computed over the header and payload using a secret key or private key). Because the signature can be verified independently, a server can trust a JWT's contents without needing to query a database or session store on every request — a property that makes JWTs attractive for stateless authentication. JWTs are commonly issued after a successful login or as the access token in an OAuth flow, then sent by the client on subsequent requests, typically in an Authorization header as a bearer token. The API server verifies the signature and checks claims like expiry (`exp`) before trusting the request. Signing can use a symmetric algorithm like HMAC-SHA256, where the same secret signs and verifies, or an asymmetric algorithm like RSA or ECDSA, where a private key signs and a public key verifies — the latter is preferred when multiple services need to validate tokens without holding the signing secret. Importantly, the payload of a standard JWT is only encoded, not encrypted — anyone who intercepts the token can read its contents, so sensitive data should never be placed in the claims. JWTs also can't be easily revoked before their expiry without extra infrastructure (like a denylist), which is why many systems pair short-lived JWT access tokens with a separate, revocable refresh token. Understanding JWTs is closely tied to session management, CORS behavior for cross-origin API calls, and general authentication design.

Key Concepts

Three-part structure: header, payload, and signature, each Base64URL-encoded
Self-contained — claims can be verified without a server-side lookup
Signed (not encrypted by default), so contents are readable but tamper-evident
Supports symmetric (HMAC) and asymmetric (RSA/ECDSA) signing algorithms
Standard claims include issuer, subject, audience, expiry, and issued-at time
Commonly transmitted as a bearer token in an HTTP Authorization header
Stateless by design, reducing database load for authentication checks
Cannot be revoked before expiry without additional infrastructure

Use Cases

Stateless API authentication between a frontend and backend or microservices

Carrying identity and permission claims in OAuth 2.0 / OpenID Connect flows

Single sign-on tokens shared across multiple services or subdomains

Short-lived access tokens paired with a longer-lived refresh token

Signed data exchange between trusted backend services

Email verification and password-reset links with an embedded expiry claim

Frequently Asked Questions

From the Blog

AI & Technology

Large Language Models (LLMs) Explained for Beginners

An LLM predicts the next piece of text, one token at a time — this guide explains how ChatGPT, Claude, and Gemini actually work.

Python File I/O: Reading and Writing Files

Almost every real Python program reads or writes files — logs, configs, CSVs, JSON, reports. This guide covers text files, CSV, JSON, binary files, and the modern pathlib approach, with best practices for safe file handling.

Learn Node.js Through Building a Music API

Node.js is JavaScript on the server, and building a REST API for your music collection is the perfect first project. This guide covers Express routes, middleware, JSON responses, and deploying to a free hosting service — all by building an API for a music playlist.

How Large Language Models Actually Work

LLMs seem magical until you understand what they are: next-token predictors trained on massive text corpora. This guide explains tokenisation, embeddings, the transformer architecture, attention mechanism, and how training works — without requiring a maths degree.