What Is a JWT? JSON Web Token Structure, Signing, and Verification Explained

After logging into a web service, have you ever spotted a long string starting with "eyJ..." in your browser's developer tools? Or read instructions to attach a header like "Authorization: Bearer eyJ..." when calling an API? That string beginning with "eyJ" is exactly the subject of this article: the JWT (JSON Web Token). Here we explain, step by step and for beginners, what a JWT is, what structure it has, why it can be used safely, and the cautions you cannot ignore when using it.

What Is a JWT

JWT (pronounced "jot") stands for "JSON Web Token," a compact, self-contained standard format for securely exchanging information between parties. It is defined by the specification RFC 7519. "Self-contained" means that the token itself carries the necessary information, such as "who" it represents and "until when" it is valid.

The most representative use is authentication and authorization. For example, when a user logs in successfully, the server issues a JWT that represents that user. From then on, the client (browser or app) sends this JWT with each request, and by verifying the received JWT, the server can determine that "this request really comes from that logged-in user." A major characteristic is that the server can confirm identity simply by checking the token, without querying the database every time.

Although a JWT looks like a meaningless string, it does not hide its content with encryption. It is purely a mechanism that guarantees "this information was indeed created by the issuer and has not been altered along the way." We will explain this in detail later.

The Three Parts: header.payload.signature

A JWT consists of three parts separated by periods (.). A real token looks like this.

xxxxx.yyyyy.zzzzz

Each part has the following role.

• Header: indicates the "type" of the token and the "algorithm used for signing." For example, it carries information as JSON such as "typ is JWT" and "alg is HS256."
• Payload: the actual data you want to convey. Things like the user ID, permissions, and expiration are stored as JSON in name-value pairs called "claims."
• Signature: a value that guarantees the header and payload have not been tampered with. It is designed so that only the issuer can create it.

In other words, it helps to think of a JWT as a set of three: "meta information (header)," "content (payload)," and "a seal that prevents tampering (signature)." The first two are converted from JSON, and the third is the value that protects that JSON.

Base64URL Encoding and the Fact That Anyone Can Read It

The header and payload are originally JSON, but as-is they may contain characters (symbols, line breaks, etc.) that are inconvenient to include in a URL or HTTP header. So they are converted into a string using a scheme called Base64URL before being joined with periods. The common opening "eyJ" comes from the fact that JSON always begins with a brace "{" and a quote, which becomes "eyJ" when converted to Base64URL.

What is critically important here is that Base64URL is not encryption; it is merely encoding (a change of representation). Anyone can convert it back to the original JSON without a key. This means that anyone who obtains the token can read the contents of a JWT's header and payload. To see what your JWT actually contains, paste it into the JWT Decoder, which displays the header and payload in formatted form. If you want to try Base64URL conversion itself, use the Base64 Converter to encode and decode strings and feel how the mechanism works.

You may wonder, "If it can be read, why is it safe to use?" The answer is the signature, explained next.

How Signing and Verification Work

The third part, the signature, is the very heart that supports the security of a JWT. The signature is a value computed by taking the header and payload (in their Base64URL form) together and using a secret key known only to the issuer. Representative schemes include HMAC (such as HS256), which computes with a shared secret key, and RSA and ECDSA (such as RS256), which use a pair of private and public keys.

The receiving server recomputes the signature itself from the same header and payload and checks whether it matches the signature attached to the token. If they match, it can conclude that "this token was created by the issuer who holds the correct key, and neither the header nor the payload has been tampered with." If someone arbitrarily rewrites the user ID or permissions in the payload, the signature will no longer match, so the fraud is immediately detected.

What matters here is that the signature is not for "hiding the content" but for "detecting tampering." The content can be read by anyone, but a third party without the key cannot create a valid signature, so they cannot rewrite the content and make it consistent. This is the essence of why a JWT is "safe even though it is readable."

The signature is a seal for detecting tampering. What is kept secret is not the "content" but the "key."

Expiration (exp) and Common Claims

The name-value pairs stored in the payload are called claims. Among the representative claims whose meaning is predefined by the specification are the following.

Especially important is exp (expiration). Once a JWT is issued, its verification is completed by its content alone. Conversely, this means a leaked token can be abused as long as it is within its validity period. Therefore, it is common to set a short expiration (a few minutes to a few hours) and reissue the token once it expires. These times are often expressed as the number of seconds elapsed since January 1, 1970 (UNIX time), so decoding is also useful when you want to convert them into a human-readable date and time.

In addition to these standard claims, you can freely include information defined by the app itself (such as a role or display name). However, you must be careful about what you put in, as described next.

Uses and Cautions: Do Not Put Secrets Inside

A JWT is convenient, but misunderstanding its nature can lead to unexpected accidents. To use it safely, keep the following points in mind.

• Do not put sensitive information in the payload: as noted, the payload can be decoded and read by anyone without a key. You must not include secrets such as passwords, credit card numbers, or national ID numbers. The signature only prevents tampering; it does not hide the content.
• Always verify the signature: trust a received JWT only after verifying its signature on the server side. In particular, beware of the classic attack of rewriting the header's alg to "none (no signature)," and of implementation mistakes that accept unexpected algorithms.
• Set an appropriate expiration: set exp so that even if a token leaks, the damage is limited by time. For maintaining long-term login, combine it with a separate mechanism such as a refresh token.
• Always send and receive over HTTPS: if a token is intercepted, impersonation becomes possible. Always encrypt communications.

In summary, the essence is that a JWT has a three-part structure of "header, payload, signature," its Base64URL-represented content can be read by anyone, but tampering can be detected through the key-based signature. That is exactly why it is important to use it with the understanding that "the content cannot be kept secret" and "managing the key and expiration is essential." To understand more deeply, check what claims a real token holds with the JWT Decoder, and try the encoding mechanism with the Base64 Converter.

Please note that this article is intended to provide general information. Because authentication and authorization implementations are directly tied to security, when adopting them in an actual system, consult the latest official specifications (such as RFC 7519), the documentation of trusted libraries, and security professionals, and choose a method suited to your use.