JWT
A JWT is a small digital ID document that a server issues and protects against forgery with a signature. It lets a program prove who it is with every request, without the server having to remember it.
When you log in to a website, the server checks your password once. After that, it doesn’t want to ask who you are again with every click. So it issues you a kind of admission ticket: a small text file containing your name and an expiration date. This ticket carries a mathematical checksum that only the server can generate. A JWT is exactly such a ticket, stored in a simple, globally standardized text format. Your browser automatically sends it along with every further request.
Why servers no longer want to remember anyone
Login used to work differently. The server created an entry in its memory for each logged-in user, called a session. The browser only received a number that the server used to find this entry again. This works well as long as a single server handles everything.
But large services run on hundreds of machines simultaneously. Your next request might land on a completely different server than the last one. That server doesn’t know your memory entry. All servers would then need to constantly synchronize with each other, which costs time and technical effort.
A JWT solves this the other way around. All the necessary information is contained in the token itself. Any server can check the signature and immediately knows what’s going on, without having to look anything up anywhere. Experts call this stateless. This is exactly why the method has become standard for modern apps and cloud services.
Three parts, separated by dots
A JWT looks like a long string of characters with two dots in it. The three sections are called header, payload, and signature. The header names the signature method used. The payload contains the actual data, such as the user ID, the role, and the expiration time.
An important misconception: the first two parts are not encrypted. They are merely re-encoded into a space-saving format that anyone can convert back in seconds using an online tool. A JWT is thus readable like a postcard. Passwords or account details have no business being in it.
The protection lies solely in the third part. The server computes a checksum from the header and payload together with a secret key. If someone changes even a single character in the payload, the checksum no longer matches. The server detects the forgery and rejects the request. So anyone who wants to secretly change their role to “administrator” fails because of the signature.
One drawback remains: a token that has been issued is valid until it expires. The server cannot simply revoke it, because it doesn’t store anything. That’s why validity is often set to just a few minutes, and the token is renewed in the background.
Where JWTs show up in everyday life
Almost every mobile app that has a login works with such tokens in the background. Even the “Sign in with Google” button delivers one. Google confirms your identity within it, and the third-party site checks the signature without ever seeing your password.
JWTs are especially important for AI services. Anyone using an interface to a language model sends along a token with every request. This lets the provider identify the account and bill for the computing costs incurred. With millions of requests per minute, querying a central database would be a real bottleneck.
JWTs regularly appear in news about security vulnerabilities. Usually, this is not about broken encryption, but about sloppy implementation. A common mistake was that servers blindly trusted the specification in the header and accepted tokens without any signature at all. Such vulnerabilities show: the method itself is solid, what matters is careful programming.