JWT Decoder & Encoder Online
Decode JWT tokens to inspect their contents, or build and sign your own JWT instantly. Everything runs locally in your browser.
Invalid JWT token. Please check the format.
Only HMAC algorithms can be signed client-side. RS256 / ES256 need a private key — sign those on your server.
Used only in your browser to compute the signature.
Invalid JSON in header or payload.
What is a JWT Token?
JWT stands for JSON Web Token. It is an open standard (RFC 7519) for securely transmitting information between two parties as a compact, self-contained JSON object. JWTs are the most widely used format for authentication tokens in modern web applications and APIs.
When you log in to a web app, the server typically generates a JWT and sends it to your browser. Your browser then includes that token on every subsequent API request. The server reads the token, verifies its signature, and knows who you are — without needing to look up a session in a database.
JWT Token Structure
A JWT consists of three Base64URL-encoded parts separated by dots:
Each part is independently Base64URL encoded. The encoding is not encryption — the content can be read by anyone who has the token. Only the signature part verifies authenticity.
The Header
The header is a JSON object that describes the token type and the signing algorithm used. It is always Base64URL encoded.
"alg": "HS256",
"typ": "JWT"
}
Common algorithm values: HS256 (HMAC + SHA-256, symmetric key), RS256 (RSA + SHA-256, asymmetric), ES256 (ECDSA, asymmetric). The algorithm determines how the signature is created and verified.
The Payload (Claims)
The payload contains claims — statements about the user and any additional metadata. There are three types of claims:
- Registered claims — Standardized fields defined in the JWT spec. Not required but recommended.
- Public claims — Custom claims registered in the IANA JWT Claims Registry to avoid collisions.
- Private claims — Custom claims agreed upon between the issuer and consumer.
Common registered claims and what they mean:
"sub": "1234567890", // Subject — who the token refers to (usually user ID)
"iss": "myapp.com", // Issuer — who created the token
"aud": "api.myapp", // Audience — who the token is intended for
"exp": 1716000000, // Expiry — Unix timestamp when the token expires
"iat": 1715996400, // Issued At — Unix timestamp when the token was created
"nbf": 1715996400, // Not Before — token is invalid before this time
"jti": "abc123" // JWT ID — unique identifier for this token
}
The Signature
The signature is what makes JWTs trustworthy. It is created by taking the encoded header, a dot, the encoded payload, then signing that string using the algorithm and secret key specified in the header.
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)
If anyone tampers with the header or payload after the token is issued, the signature becomes invalid. The server detects this on verification and rejects the token.
Important: Decoding a JWT only reads the header and payload — it does not verify a signature. Building one with the Encode tab signs it with the algorithm and secret you choose. Only a server holding the correct secret (or public key, for asymmetric algorithms) can verify that a token is authentic.
How to Encode (Generate) a JWT
Use the Encode tab to build and sign your own token, entirely in your browser:
- Edit the Header JSON — usually you only need to leave
typ: "JWT"as is - Edit the Payload JSON with the claims you want —
sub,exp, and any custom fields - Choose a signing Algorithm — this also sets the
algfield in the header automatically - Enter a Secret Key — the token signs itself as you type
- Copy the result and use it for testing an API, seeding a database, or debugging an auth flow
The signature is computed using the browser's native crypto.subtle.sign() Web Crypto API — no external library is loaded and no data is sent anywhere.
Choosing a Signing Algorithm
| Algorithm | Hash | Key type | Notes |
|---|---|---|---|
| HS256 | SHA-256 | Shared secret | Most common default, supported everywhere |
| HS384 | SHA-384 | Shared secret | Longer signature, rarely required |
| HS512 | SHA-512 | Shared secret | Longer signature, rarely required |
| RS256 | SHA-256 | RSA private/public key pair | Not supported here — sign server-side |
| ES256 | SHA-256 | ECDSA private/public key pair | Not supported here — sign server-side |
Asymmetric algorithms (RS256, ES256) exist so that one service can sign with a private key while many other services verify with the matching public key, without ever sharing the private key. That setup belongs on a server, not in a browser tool — which is why this encoder only supports the HMAC family.
Equivalent Code in Node.js
The token this tool generates is identical to what a backend library would produce. For reference, here is the same operation using the popular jsonwebtoken package:
const token = jwt.sign(
{ sub: '1234567890', name: 'John Doe' },
'your-256-bit-secret',
{ algorithm: 'HS256', expiresIn: '1h' }
);
JWT vs Session Tokens
The key difference between JWTs and traditional session tokens is where the data lives:
- Session tokens — A random string that maps to session data stored server-side (in a database or cache). Every request requires a database lookup.
- JWTs — All the data the server needs is embedded in the token itself. No database lookup needed. This makes JWTs ideal for stateless APIs and microservices.
The tradeoff: JWTs cannot be easily invalidated before expiry since the server holds no state. Session tokens can be deleted from the database immediately to log a user out.
JWT Acronym and Pronunciation
JWT stands for JSON Web Token. It is pronounced either as individual letters ("J-W-T") or as the word "jot." Both are widely accepted. The standard is defined in RFC 7519, published by the IETF.
What JWT Tokens Are Used For
- Authentication — Verifying a user's identity after login. The most common use case.
- Authorization — Encoding roles and permissions so the server can make access control decisions without a database call.
- Information exchange — Passing verified data between services in a microservice architecture.
- Single Sign-On (SSO) — Sharing authentication across multiple domains or services.
Security: What Not to Put in a JWT
Because the payload is only Base64 encoded (not encrypted), anyone holding the token can read its contents. Never include sensitive data in a JWT payload:
- Passwords or password hashes
- Credit card numbers or financial data
- Personal identification numbers (SSN, passport, etc.)
- Private keys or API secrets
If you need to transmit sensitive data in a token, use JWE (JSON Web Encryption), which encrypts the payload, rather than plain JWT.
How to Use This Tool
Decoding a token:
- Paste any JWT token into the text area on the Decode tab
- The decoder splits the token at the dots and decodes each part
- The Header shows the algorithm and token type
- The Payload shows all claims including expiry as a readable date
- The Signature is shown raw — it cannot be decoded without the secret key
Encoding a token:
- Switch to the Encode tab
- Edit the header and payload JSON to match what you need
- Pick an algorithm and enter a secret key
- Copy the generated token from the result box
Frequently Asked Questions
What does JWT stand for?
JWT stands for JSON Web Token. It is an open standard (RFC 7519) for representing claims securely between two parties using a compact, URL-safe string format.
What is a JWT access token?
A JWT access token is a JWT used to grant access to protected API resources. It is issued by an authorization server after successful login and typically has a short expiry time (minutes to hours). It is sent in the HTTP Authorization header as a Bearer token on API requests.
What is the JWT payload?
The JWT payload is the middle section of the token. It contains claims — JSON key-value pairs that carry information about the user, permissions, and token validity period. It is Base64URL encoded, not encrypted, so it can be read by anyone with the token.
What is a JWT signing key?
The signing key is the secret used to create the token's signature. For symmetric algorithms like HS256, it is a shared secret known to both the issuer and verifier. For asymmetric algorithms like RS256, the issuer signs with a private key and verifiers check using the corresponding public key.
Can I verify a JWT signature with this tool?
The Decode tab does not verify signatures, since that requires the secret key. If you know the secret a token was signed with, switch to the Encode tab, rebuild the same header and payload, sign it with that secret, and compare the result to the original token — if they match, the signature is valid.
Are expired JWTs still decodable?
Yes. Expiry (the exp claim) is just a number inside the payload. Decoding reads the payload regardless of whether the token has expired. Expiry is only enforced during signature verification on the server — the server checks the exp value and rejects expired tokens. This decoder shows you the expiry date so you can see if a token has expired.
How do I create or encode a JWT online?
Switch to the Encode tab, edit the header and payload JSON, choose a signing algorithm (HS256, HS384, or HS512), and enter a secret key. The tool builds and signs the token entirely in your browser using the Web Crypto API and updates the result as you type.
What algorithm should I use to sign a JWT?
HS256 is the most common choice for symmetric signing and is supported by virtually every JWT library. Use HS384 or HS512 only if you have a specific requirement for a longer hash output. Asymmetric algorithms like RS256 or ES256 use a private and public key pair instead of a shared secret and are not supported by this browser-based encoder — sign those on your server.
Is it safe to enter my real secret key into this tool?
Signing happens entirely client-side using the Web Crypto API — your secret key is never sent to any server or logged anywhere. That said, for production secrets it is still good practice to use a throwaway or test secret rather than your live signing key whenever possible.