JWT Generator

Free JWT Generator | Create and Encode JSON Web Tokens Online Instantly

Building or testing an application that uses JWT-based authentication? Thetoolity's free online JWT generator lets you create a fully encoded JSON Web Token in seconds. Customize the header, define your payload claims, set a secret key, and generate a signed token instantly. No account needed, no installation, no backend required. Perfect for developers who need a quick JWT for testing, debugging, or learning how JWTs work.

What Is a JWT (JSON Web Token)?

JWT stands for JSON Web Token. It is an open standard defined by RFC 7519 that provides a compact, self-contained way to securely transmit information between two parties as a JSON object.
The information inside a JWT can be trusted and verified because it is digitally signed. When a server issues a JWT, it signs the token using a secret key (for symmetric algorithms like HS256) or a private key (for asymmetric algorithms like RS256). Any party that receives the token can verify the signature to confirm the token has not been tampered with.
JWTs are most commonly used for authentication and authorization in web applications and APIs. Once a user logs in, the server issues a JWT. The client stores that token and sends it with every subsequent request. The server validates the token on each request without needing to look up a session in a database.

The Structure of a JSON Web Token

A JWT is made up of three parts separated by dots:
header.payload.signature
Each part is Base64URL-encoded, which means the final token is a compact string that can be safely passed in HTTP headers, URLs, and query parameters.
The Header

The header is a JSON object that describes the token. It typically contains two fields. The "alg" field specifies the signing algorithm being used, such as HS256. The "typ" field identifies the token type, which is always "JWT."
A typical header looks like this:
{ "alg": "HS256", "typ": "JWT" }

The payload contains the claims. Claims are statements about the entity, usually the user, and any additional data the application needs to pass along. There are three types of claims.
Registered claims are predefined and recommended fields. Common ones include "sub" (subject, meaning the user identifier), "iat" (issued at, a Unix timestamp of when the token was created), "exp" (expiration time), "iss" (issuer), and "aud" (audience).
Public claims are custom fields defined by the application that are shared openly. They should be registered in the IANA JSON Web Token Registry to avoid collisions.
Private claims are custom fields agreed upon by both the issuer and the consumer of the token. They are not registered and are specific to the application.

The signature is created by taking the Base64URL-encoded header, adding a dot, adding the Base64URL-encoded payload, and then hashing the combined string using the algorithm specified in the header along with the secret key.
For HS256, the signature is computed as: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
The signature ensures that if anyone changes the header or payload after the token is issued, the signature will no longer match and the token will be rejected.

How to Use Thetoolity's JWT Generator

Creating a JWT with our tool takes less than a minute.
Step 1: Review or customize the Header. The default header uses the HS256 algorithm, which is the most widely used and supported option for symmetric JWT signing. You can modify the algorithm field if needed.
Step 2: Build your Payload. The payload comes pre-filled with common demo claims including a subject, name, and issued-at timestamp. You can replace these with your own claims. Common fields to include are "sub" for the user identifier, "exp" for an expiration time (as a Unix timestamp), "iss" for the issuer name, and any custom claims your application needs.
Step 3: Enter your Secret Key. The secret key is used to sign the token. For testing purposes, any string works. For production use, your secret key should be long, random, and stored securely in an environment variable, never hardcoded in source code.
Step 4: Click "Generate JWT." The encoded token appears instantly. Copy it and use it in your requests, tests, or code.
Important note: Thetoolity's JWT generator is a demonstration and testing tool. The tokens it creates are suitable for learning, development, and API testing. For production authentication systems, always generate JWTs using a trusted library within your application's backend.

What Is HS256 and When Should You Use It?

HS256 stands for HMAC with SHA-256. It is a symmetric signing algorithm, meaning the same secret key is used both to sign the token and to verify it. This makes HS256 simple to implement and very fast.
HS256 is the right choice when all parties that need to verify JWTs are under your control and can safely share the secret key. For example, if your backend API both issues and validates JWTs, HS256 is a clean and efficient solution.
Other common JWT algorithms include the following.
HS384 uses HMAC with SHA-384 and produces a larger signature. It is used when you want a stronger hash function while still using symmetric signing.
HS512 uses HMAC with SHA-512 and produces the largest signature. It is recommended for highly sensitive applications where maximum cryptographic strength is required.
RS256 uses RSA with SHA-256 and is an asymmetric algorithm. The token is signed with a private key and verified with a public key. This is the right choice when third-party services need to verify your tokens without having access to your signing key. OAuth 2.0 providers and OpenID Connect implementations commonly use RS256.
ES256 uses Elliptic Curve Digital Signature Algorithm with SHA-256. It provides similar security to RS256 but with smaller key sizes and faster performance.
For most backend-to-backend applications and API testing, HS256 is the standard starting point.

Common JWT Claims Explained

Understanding what goes in the payload helps you build tokens that carry exactly the right information.

sub (Subject) identifies who the token is about. This is usually a user ID, like a database primary key or UUID. Example: "sub": "user_7f3a29c1"

iat (Issued At) records when the token was created, as a Unix timestamp (seconds since January 1, 1970). Example: "iat": 1716000000

exp (Expiration Time) tells recipients when the token expires, also as a Unix timestamp. Any system validating the token should reject it if the current time is past the exp value. Example: "exp": 1716003600 (one hour after iat in the example above)

iss (Issuer) identifies who created the token, typically a domain name or service name. Example: "iss": "api.yourapp.com"

aud (Audience) identifies the intended recipients of the token. A validation library should reject the token if the aud does not match. Example: "aud": "yourapp-frontend"

nbf (Not Before) specifies a time before which the token must not be accepted. Useful for issuing tokens that should only become valid in the future.

jti (JWT ID) is a unique identifier for the token itself. It can be used to prevent replay attacks by tracking which tokens have already been used.

Custom claims can be anything your application needs: user roles, permissions, tenant IDs, subscription plans, or any other data you want to carry in the token.

JWT vs Session Tokens: What Is the Difference?

Before JWTs became popular, most web applications used server-side sessions. When a user logged in, the server created a session object, stored it in a database or in memory, and gave the client a session ID as a cookie.
JWTs work differently. All the information needed to authenticate a request is stored inside the token itself. The server does not need to look up anything in a database to validate a JWT, it simply verifies the signature using the secret key.
This makes JWTs particularly well-suited for stateless APIs, microservices, and systems where multiple backend servers need to validate tokens without sharing a session store. It also makes JWTs a natural fit for mobile apps and single-page applications that communicate with APIs.
The tradeoff is that JWTs cannot be invalidated before they expire unless you implement a token blacklist or use short expiration times combined with a refresh token mechanism.

JWT Security Best Practices

Understanding how JWTs work is important. Understanding how to use them safely is just as important.
Always use HTTPS. A JWT is a bearer token, meaning anyone who possesses it can use it. Never transmit JWTs over unencrypted connections.
Use short expiration times. A token that expires in 15 minutes is far safer than one that expires in 30 days. For long-lived sessions, use short-lived access tokens paired with long-lived refresh tokens that are stored securely.
Store JWTs safely. In browser applications, avoid storing JWTs in localStorage because it is accessible to JavaScript and vulnerable to XSS attacks. Storing the token in an HttpOnly cookie prevents JavaScript from accessing it.
Validate all claims on the server. Do not trust the payload of a JWT without verifying the signature first. Always check the expiration time, the issuer, and the audience in every validation.
Never put sensitive data in the payload. The payload of a JWT is Base64URL-encoded, not encrypted. Anyone who has the token can decode and read the payload without knowing the secret key. Never put passwords, credit card numbers, or other sensitive information in the payload.
Rotate your secret keys regularly. If a secret key is compromised, all tokens signed with it must be considered invalid. Use key rotation strategies to limit the damage of a key leak.
Use strong secret keys. For HS256, your secret key should be at least 256 bits (32 bytes) of random data. Short or guessable secret keys can be brute-forced.

Where Are JWTs Used in the Real World?

JWTs appear in almost every modern web and mobile application. Here are the most common real-world uses.
API authentication is the most common use case. After a user logs in, the backend issues a JWT. The client includes this token in the Authorization header (using the Bearer scheme) for all subsequent API requests.
Single Sign-On (SSO) systems use JWTs to let a user log in once and access multiple applications. The identity provider issues a JWT that multiple services can validate without contacting the identity provider on every request.
OAuth 2.0 and OpenID Connect both use JWTs extensively. The ID token in OpenID Connect is always a JWT. Access tokens are often JWTs too, though this is not required by the OAuth 2.0 spec.
Microservices use JWTs to pass identity and authorization information between services without needing a shared session store or calling the authentication service on every inter-service request.
Email verification and password reset links sometimes use short-lived JWTs embedded in the link. The token contains the user's identity and an expiration time so the link automatically becomes invalid after a set period.

How to Decode a JWT

Any JWT can be decoded without knowing the secret key. Decoding simply means base64-decoding the header and payload to read their contents. This is not a security vulnerability because the signature still prevents anyone from modifying the token undetected.
To decode a JWT manually, split the token by the dot separator. Take the first segment (header) and the second segment (payload). Apply Base64URL decoding to each one. You will see the raw JSON of the header and payload.
Tools like jwt.io, or a JWT decoder tool on Thetoolity, can decode any JWT instantly. This is useful during development for inspecting what claims are inside a token.
To verify a JWT (confirm the signature is valid), you need the secret key (for HS256) or the public key (for RS256 and ES256). Verification is what confirms the token has not been tampered with.

Frequently Asked Questions

What is a JWT?

A JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a digitally signed JSON object. JWTs are compact, self-contained, and most commonly used for authentication in APIs and web applications.

What are the three parts of a JWT?

A JWT has three parts separated by dots: the Header, the Payload, and the Signature. The header describes the token type and signing algorithm. The payload contains the claims (user data and metadata). The signature proves the token has not been modified.

What is HS256 in JWT?

HS256 stands for HMAC with SHA-256. It is the most common symmetric signing algorithm for JWTs. It uses a single shared secret key to both create and verify the token's signature.

Is the JWT payload encrypted?

No. The payload is Base64URL-encoded, not encrypted. Anyone with the token can decode and read the payload. Never put sensitive information like passwords or personal data in the JWT payload unless you are using JWE (JSON Web Encryption) in addition to the standard JWT

What is a JWT secret key?

A JWT secret key is a string used to sign and verify JWTs when using a symmetric algorithm like HS256. The same key that signs the token must be used to verify it. The key must be kept private and should be at least 256 bits long for HS256.

What is the difference between JWT and session tokens?

Session tokens are opaque identifiers stored on the server and looked up on every request. JWTs are self-contained tokens that carry all the needed information and can be verified without any server-side storage. JWTs work better for stateless APIs and distributed systems.

Can a JWT be used without HTTPS?

You should never use JWTs without HTTPS. A JWT is a bearer token, meaning anyone who intercepts it can use it. HTTPS encryption prevents the token from being captured in transit.

How long should a JWT be valid?

For access tokens, 15 to 60 minutes is the industry standard. Shorter expiration times reduce the window of risk if a token is stolen. Use refresh tokens for long-lived sessions so users do not have to log in repeatedly.

What is the difference between JWT and OAuth?

OAuth 2.0 is an authorization framework, a set of rules for how applications can grant limited access to user accounts. JWT is a token format. OAuth 2.0 can use JWTs as access tokens or ID tokens, but OAuth 2.0 itself does not require JWTs.

Can you use this JWT generator for production?

Thetoolity's JWT generator is a testing and demonstration tool. It is ideal for generating tokens for API testing, learning how JWTs work, and debugging authentication flows. For production systems, always generate JWTs using a trusted library within your backend application and never expose your secret key in a browser tool.

What is a JWT claim?

A claim is a piece of information in the JWT payload. Registered claims are standard fields like sub (subject), exp (expiration), iat (issued at), and iss (issuer). Applications can also include custom claims to carry any additional data needed.

What happens if a JWT expires?

When a JWT's exp time is in the past, any properly implemented validation library will reject the token and return an authentication error. The client typically needs to obtain a new access token, either by using a refresh token or by asking the user to log in again.

Why Thetoolity?

Thetoolity is a growing library of free, fast, and clean online tools built for developers, engineers, and anyone working with digital data every day. Our JWT generator is one of many tools designed to eliminate friction in development and testing workflows.
No accounts. No paywalls. No bloated interfaces. Just tools that load instantly and work exactly as expected.
Explore the full collection at Thetoolity.com and find generators, converters, calculators, checkers, and testers, all free and all instant.