What is a JSON Web Token (JWT)?

A JWT is a compact, URL-safe token format defined by RFC 7519 for securely transmitting claims between two parties. It consists of three Base64URL-encoded parts separated by dots: a header (algorithm and token type), a payload (claims like sub , iat , exp ), and a signature. The signature ensures the token has not been tampered with, but the payload is only encoded — not encrypted — so never store secrets in it. Use our Base64 Encoder to inspect the raw segments yourself.

What is the difference between JWT and session cookies?

Session cookies store a session ID on the client while the server keeps the actual state in a database or in-memory store. JWTs are self-contained: the server can validate them using only the signing key, with no database lookup required. This makes JWTs well-suited for stateless architectures, microservices, and cross-domain auth where a shared session store would add complexity. The trade-off is that JWTs cannot be individually revoked without extra infrastructure (e.g., a deny-list), whereas server-side sessions can be destroyed instantly.

What is the difference between HS256 and RS256?

HS256 (HMAC-SHA256) is a symmetric algorithm — the same secret is used to both sign and verify the token. RS256 (RSA-SHA256) is asymmetric: a private key signs the token and a separate public key verifies it. Use HS256 when only your own backend issues and validates tokens, because it is faster and simpler. Use RS256 when third parties need to verify tokens without access to the signing key, such as in OpenID Connect, multi-service architectures, or public APIs. Verify your key length with a Base Converter — HS256 requires at least a 256-bit (32-byte) secret.

What are the main security risks of using JWTs?

The most common pitfalls include: (1) using the none algorithm, which disables signature verification entirely — always validate the alg header server-side; (2) storing sensitive data in the payload, since it is merely Base64URL-encoded and readable by anyone; (3) setting excessively long expiration times, which widens the window for token misuse; (4) accepting tokens without verifying the signature or the iss and aud claims. Always prefer short-lived access tokens paired with refresh tokens, and rotate your signing keys regularly.

When should I use JWTs instead of other token formats?

JWTs are the right choice when you need stateless authentication across distributed services, when tokens must be validated without a central database call, or when you need to pass structured claims (roles, scopes, tenant IDs) between services. They are widely adopted in OAuth 2.0 and OpenID Connect flows. For simple single-server apps, traditional session cookies may be easier to manage. If you need unique, non-guessable identifiers rather than signed claims, consider a UUID instead.

Are JWTs generated with this tool secure?

Yes. All signing and verification happens entirely in your browser — your secret keys and payloads are never sent to any server. The tool uses the Web Crypto API for HMAC operations, the same cryptographic primitives used by major browsers and Node.js. That said, this tool is designed for development, debugging, and learning; in production, always generate and verify tokens server-side with a battle-tested library. You can cross-check payload timestamps with our Timestamp Converter .

JWT Generator & Verifier

Free online JWT generator and verifier for signing and decoding JSON Web Tokens with HS256/384/512 algorithms

Sign JWT Token

Payload (JSON)

Algorithm

Secret Key

Signing Information

• HS256/384/512 use HMAC with SHA-256/384/512

• Payload can include any JSON data (claims)

• Keep your secret key secure and never expose it

• Generated tokens are signed but not encrypted

JWT Guide

Anatomy of a JWT

A JSON Web Token consists of three Base64URL-encoded segments separated by dots: header.payload.signature. Understanding each part is essential for debugging auth issues and building secure systems.

The header is a JSON object specifying the token type ("typ": "JWT") and the signing algorithm ("alg": "HS256"). The payload contains claims — statements about the user and metadata. The JWT specification (RFC 7519) defines several registered claims:

iss (issuer) — who created the token
sub (subject) — the user or entity the token represents
aud (audience) — the intended recipient service
exp (expiration) — Unix timestamp after which the token is invalid
iat (issued at) — Unix timestamp of token creation. Convert these with our Timestamp Converter.
jti (JWT ID) — a unique identifier to prevent replay attacks, often a UUID

The signature is computed over the encoded header and payload using the specified algorithm and a secret key. It guarantees integrity — if anyone modifies the header or payload, the signature verification will fail. Crucially, the payload is only encoded, not encrypted. Decode any JWT with our Base64 decoder to see the raw claims.

JWT vs Session Cookies vs OAuth

Choosing the right authentication mechanism depends on your architecture and threat model:

Session cookies are the traditional approach. The server stores session state (in memory, Redis, or a database) and sends only a session ID to the client as an HTTP-only cookie. Advantages: sessions can be revoked instantly by deleting server-side state, and cookies are automatically sent with every request via the browser. Drawbacks: they require a shared session store in multi-server deployments and do not work across different domains without extra configuration.

JWTs are stateless — the token itself carries all the information the server needs. No database lookup is required to validate a request. This makes JWTs ideal for microservices, where dozens of services need to verify identity without a central session store. The trade-off is that revoking a JWT before its expiration requires a deny-list, adding back some statefulness.

OAuth 2.0 is not an authentication protocol but an authorization framework. It defines how a client obtains an access token (often a JWT) from an authorization server to access protected resources. OpenID Connect (OIDC) layers authentication on top of OAuth by adding an ID token (always a JWT). In practice, most modern auth flows combine OAuth/OIDC for token issuance with JWTs as the token format.

JWT Security Best Practices

JWTs are powerful but easy to misuse. Follow these guidelines to avoid the most common vulnerabilities:

Keep expiration short: Access tokens should live 5-15 minutes. Use refresh token rotation — issue a new refresh token with every access-token refresh and invalidate the old one. This limits the damage window if a token is leaked.
Validate aud and iss: Always verify that the audience claim matches your service and the issuer is a trusted authority. Without this check, a token intended for Service A could be replayed against Service B.
Rotate signing keys: Publish keys via a JWKS (JSON Web Key Set) endpoint and rotate them periodically. Asymmetric algorithms (RS256, ES256) make rotation easier because services only need the public key.
Never store secrets in the payload: The payload is Base64URL-encoded, not encrypted. Anyone intercepting the token can read every claim. Use encrypted JWTs (JWE) if payload confidentiality is required.
Block the none algorithm: Your server must reject tokens with "alg": "none". This header disables signature verification entirely — a classic exploit. Validate the algorithm server-side against a whitelist.
Use httpOnly and secure cookies: When storing JWTs in cookies, set both flags to prevent JavaScript access and enforce HTTPS transmission. Verify your token structure with our JSON Validator.

Frequently Asked Questions

UUID

Generate v4, v7, ULID

Hash

MD5, SHA, BLAKE2/3

Encode

Base64, URL, HTML, Hex

JSON

Validate, format & convert JSON

Anatomy of a JWT

iss (issuer) — who created the token
sub (subject) — the user or entity the token represents
aud (audience) — the intended recipient service
exp (expiration) — Unix timestamp after which the token is invalid
iat (issued at) — Unix timestamp of token creation. Convert these with our Timestamp Converter.
jti (JWT ID) — a unique identifier to prevent replay attacks, often a UUID

JWT Generator & Verifier

Sign JWT Token

Signing Information

JWT Guide

Anatomy of a JWT

JWT vs Session Cookies vs OAuth

JWT Security Best Practices

Frequently Asked Questions

What is a JSON Web Token (JWT)?

What is the difference between JWT and session cookies?

What is the difference between HS256 and RS256?

What are the main security risks of using JWTs?

When should I use JWTs instead of other token formats?

Are JWTs generated with this tool secure?

You Might Also Like

UUID

Hash

Encode

JSON

Sign JWT Token

Signing Information

JWT Guide

Anatomy of a JWT

JWT vs Session Cookies vs OAuth

JWT Security Best Practices

Frequently Asked Questions

What is a JSON Web Token (JWT)?

What is the difference between JWT and session cookies?

What is the difference between HS256 and RS256?

What are the main security risks of using JWTs?

When should I use JWTs instead of other token formats?

Are JWTs generated with this tool secure?