A JSON Web Token (JWT) is a compact, URL-safe credential defined in RFC 7519 by the IETF. It consists of three Base64URL-encoded parts, header, payload, and signature, joined by dots. The server issues a JWT after authentication; the client attaches it to subsequent requests via the Authorization: Bearer header. Because the signature can be verified locally without a session lookup, JWTs are stateless and work well across microservices, mobile applications, and distributed APIs.

JWE (JSON Web Encryption, RFC 7516) is the encrypted variant of a JSON Web Token. Unlike JWS (JSON Web Signature), which is what most people mean when they say "JWT", JWE encrypts the payload so it cannot be read without the decryption key. Use JWE when the payload contains data that must not be readable by the token holder. This tool handles JWS only; JWE requires a separate encryption key setup.

JWT Decoder & Encoder

Q: What does JWT stand for?

JWT stands for JSON Web Token, pronounced "jot", an open standard (RFC 7519) published by the Internet Engineering Task Force (IETF). The abbreviation is used interchangeably with the full name across authentication libraries, specifications, and documentation.

Q: Is it safe to decode JWTs online?

Yes, with one caveat. Decoding reads Base64URL-encoded content, it does not require or expose the signing secret. The payload of any JWT is already readable by anyone who holds the token, because it is encoded rather than encrypted. That said, avoid pasting tokens containing personal user data (names, email addresses, national IDs) into any online tool on a shared or monitored network. This tool processes everything locally in your browser, nothing is transmitted or stored anywhere.

Q: What are the parts of a JWT?

A JWT has three parts separated by dots. The header holds the signing algorithm (alg) and token type (typ). The payload holds the claims, user ID, expiry time, roles, and any custom data. The signature is a cryptographic hash of the header and payload created with the signing key. Paste any JWT into the decoder above to see all three displayed as formatted JSON.

Q: Why would I decode a JWT?

Decoding a JWT is the fastest way to debug authentication failures. When an API returns 401 or 403, decoding the token immediately shows whether exp has passed, whether aud matches the expected service, which algorithm was used, and what claims the token actually carries. It is faster than adding log statements and redeploying.

Q: Why would I encode a JWT?

You encode a JWT to generate signed tokens for testing and integration work. For example, encode a token with a specific user ID and role to verify that your API correctly enforces access control rules. You can also encode tokens to replicate a production authentication flow in a staging environment without requiring a real login, or to test how your server responds to tokens with expired, missing, or unexpected claims.

Q: What is signature verification and why does it matter?

Signature verification confirms a JWT was signed by a trusted issuer and has not been modified since. Without it, any actor can decode a token, alter the payload (changing a "role": "user" to "role": "admin", for instance), re-encode it, and present it as valid. Only a valid, verified signature means the claims can be trusted. This is the core security guarantee of JWS (RFC 7515).

Q: What is the difference between HS256 and RS256?

HS256 (HMAC-SHA256) is symmetric, the same 256-bit secret is used to encode (sign) and verify tokens. RS256 (RSASSA-PKCS1-v1_5 with SHA-256) is asymmetric, a private key encodes (signs) the token and a public key verifies it. Use HS256 when one service controls both issuing and verifying. Use RS256 (or PS256 for stronger security) when independent services need to verify tokens without sharing the signing secret. The public key in RS256/PS256 can be published openly; the private key never leaves the auth server.

Q: What does "jwt expired" mean?

A JWT is expired when the current Unix timestamp is greater than the value of the exp claim. The exp field is a NumericDate, seconds since 00:00:00 UTC on 1 January 1970. Most servers automatically reject expired tokens to prevent indefinitely valid credentials. To check manually: decode the token, read exp, and compare it to Math.floor(Date.now() / 1000) in JavaScript or int(time.time()) in Python.

Q: What is a JWT secret key?

A JWT secret key (used with HMAC algorithms) is the shared value that both signs new tokens and verifies existing ones. Anyone with the secret can forge arbitrary claims, so it must stay private. The NIST minimum recommendation for HMAC-SHA256 keys is 256 bits (32 bytes). Use the generator on this page for a cryptographically random key at the right length, then store it in an environment variable or a secrets manager, never in source code or configuration files tracked by version control.

JWT authentication failures are opaque. A 401 response tells you nothing, you can't see whether the token expired, whether the audience claim is wrong, which algorithm was used, or whether the payload was tampered with. Most online tools only decode: they can't encode a new token, verify a signature, or generate keys, and many send your tokens to external servers.

This tool handles all four JWT operations in one place, decode, encode, verify, and generate keys, with full support for HMAC (HS256, HS384, HS512), RSA, and RSA-PSS algorithms. Inspect any token's claims without a signing key, encode new tokens with custom payloads, verify signatures against secrets or public keys, and generate cryptographically secure random keys ready for production. Everything runs in your browser via the Web Crypto API, no token, key, or payload leaves your device.

100% Private, runs in your browser

Free, no account needed

Supports HMAC, RSA & RSA-PSS

No account or signup required

Decode JWT

Encoded JWT

Encode JWT

Secret key

Header (JSON)

Payload (JSON)

Verify JWT signature

JWT to verify

Secret key

JWT secret key generator

What Is a JWT Decoder?

A JWT decoder, also called a JWT parser, debugger, or viewer, is a tool that splits a JSON Web Token into its three parts: header, payload, and signature, displaying each as readable JSON. A JWT encoder does the reverse: it takes a header, payload, and signing key, and produces a signed compact token. JSON Web Token (JWT, pronounced "jot") is an open standard defined by the IETF in RFC 7519 for transmitting verified claims between two parties as a compact, URL-safe string.

JWTs are the foundation of stateless authentication in modern web architecture. After a user logs in, the authorization server issues a signed JWT containing verified claims, a user ID, role, expiry time, and returns it to the client. The client attaches that token to every subsequent API request. The server checks the digital signature without consulting a session store, which makes the system fast and scalable across microservices. In most systems, a short-lived access token and a longer-lived refresh token are issued together, the access token carries the JWT claims, while the refresh token is used to request a new one after expiry.

The two most common protocols that depend on JWTs are OAuth 2.0 (authorisation) and OpenID Connect (OIDC, identity and authentication). In both, JWTs carry standardised claims defined in RFC 7519. Google, Microsoft, Okta, and Auth0 all issue OIDC ID tokens as JWTs.

Unlike the jwt-decode npm package, which only decodes tokens, this tool also encodes and decodes tokens with any HMAC or RSA algorithm, verifies signatures, and generates secret keys, all without leaving your browser. Major JWT libraries in other languages include PyJWT (Python), jjwt (Java), golang-jwt (Go), and jose (Rust), use this tool to test tokens generated by any of them.

How to Use This Tool

Decode a JWT

Paste the encoded JWT you want to inspect into the Decode JWT field.
Click Decode JWT.
The header and payload appear as formatted JSON, you can see every claim the issuer chose to encode into the token. Check claims, algorithm, expiry timestamp, issuer, and any custom fields, no signing key required.

Encode a JWT

Select a signing algorithm from the dropdown, HS256 to encode with HMAC, RS256 or PS256 to encode with RSA.
Enter your secret key (HMAC) or private key in PEM format (RSA / RSA-PSS).
Edit the Header JSON to set alg and typ.
Edit the Payload JSON with your claims, sub, iat, exp, roles, or any custom fields.
Click Encode JWT to encode and sign your token in one step.

Verify a JWT Signature

Paste the token into the Verify JWT field.
Enter the secret key (HMAC) or public key in PEM format (RSA / RSA-PSS). The algorithm is read from the token header automatically.
Click Verify JWT. The tool re-runs the same process used to encode the signature and compares the result. Valid = signature matches. Invalid = wrong key or tampered payload.

Generate a Secret Key

Select key length, 256-bit for HS256, 384-bit for HS384, 512-bit for HS512.
Click Generate Secret.
Copy and store the key in an environment variable or secrets manager. Never put signing secrets in source code. For additional secret formats, see our Password Generator.

How to Read Your Results

Decoded header

The decoded header reveals the settings chosen when the JWT was encoded. It is a JSON object with two standard fields: alg (the signing algorithm, "HS256", "RS256", "PS256", etc.) and typ (always "JWT"). If a kid (Key ID) field is present, it identifies which key was used to sign the token, used when an authorisation server publishes multiple public keys via a JWKS (JSON Web Key Set) endpoint and rotates them over time.

Decoded payload

The payload contains the token's claims, data about the authenticated subject. Standard registered claims include sub (subject, typically a user ID), iss (issuer), aud (audience), exp (expiration, a Unix timestamp), iat (issued at), nbf (not before), and jti (JWT ID). Custom claims your application adds, roles, organisation IDs, permission scopes, subscription tier, also appear here.

The payload is Base64URL-encoded, not encrypted. Anyone with the token can decode and read the payload. Never store passwords, payment details, national IDs, or sensitive personal data in a JWT payload. For tokens that must carry sensitive data, use JWE (RFC 7516) instead.

Signature verification result

Verification recomputes the signature that was created when the token was encoded, using the header, payload, and the key you provide, then compares it byte-by-byte against the signature encoded in the token. Valid confirms the token was signed by the holder of that key and nothing has been altered. Invalid means the key is wrong or the token was tampered with after signing. Decoding alone never proves authenticity, always verify before acting on any claim in production.

JWT Token Structure

A JWT is three Base64URL-encoded strings joined by dots: [header].[payload].[signature]. When you encode a JWT, each section is Base64URL-encoded and joined with dots. When you decode it, each section is separated and displayed as JSON. The header identifies the algorithm. The payload carries the claims. The signature proves neither has been altered.

[header].[payload].[signature]

Here is a sample JWT token showing how the three parts are divided:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9          ← header
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ  ← payload
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  ← signature

Paste this sample JWT into the decoder above to see each part decoded.

Header

The header is a JSON object you encode into the JWT as Base64URL. It specifies the token type ("JWT") and the algorithm used to create the signature, for example "HS256" (HMAC-SHA256) or "RS256" (RSASSA-PKCS1-v1_5). Some tokens include a kid (Key ID) to tell the recipient which public key to use for verification when the issuer rotates keys.

Payload

The payload is a JSON object containing the claims, Base64URL-encoded but not encrypted. RFC 7519 defines three categories of claims: registered claims (standardised names like sub, iss, exp), public claims (registered in the IANA JSON Web Token Claims registry to prevent collisions), and private claims (custom, application-specific fields agreed between issuer and consumer).

Signature

The signature is the digital signature that makes JWTs tamper-proof, it binds the header and payload together and proves they came from a trusted source. For HMAC algorithms, it is HMACSHA256(base64url(header) + "." + base64url(payload), secret). For RSA, a private key signs and any holder of the matching public key verifies. Change a single byte in the header or payload after signing and the signature becomes invalid, which is the core security guarantee of JWS (RFC 7515).

Common JWT Claims

JWT registered claims are standardised field names defined in RFC 7519. The most important are exp (expiration time), sub (subject, usually a user ID), iss (issuer), and aud (audience). All are optional but widely implemented across OAuth 2.0 and OIDC systems.

RFC 7519 registered claim names, optional but widely supported across OAuth 2.0 and OIDC systems:

Claim	Full Name	Type	Example Value	Description
iss	Issuer	String/URI	"https://auth.example.com"	The server or app that issued the token
sub	Subject	String	"user_abc123"	Who the token is about, usually a user ID
aud	Audience	String/Array	"api.example.com"	Which service(s) must accept this token
exp	Expiration Time	NumericDate	1716239022	Unix timestamp, token is invalid after this point
nbf	Not Before	NumericDate	1716235422	Token must not be accepted before this timestamp
iat	Issued At	NumericDate	1716235422	When the token was created
jti	JWT ID	String	"a1b2c3d4e5"	Unique identifier; used to prevent replay attacks
kid	Key ID	String	"2025-key-01"	Identifies which key signed the token when multiple keys are in use

NumericDate values (exp, nbf, iat) are seconds since the Unix epoch, 00:00:00 UTC on 1 January 1970.

When you encode a JWT, add private claims for app-specific data: roles, subscription tier, org ID, permission scopes. Use a URI-style name such as "https://yourapp.com/role" to avoid future IANA registry collisions.

Supported Signing Algorithms

This tool supports all three HMAC variants (HS256, HS384, HS512) and all six RSA / RSA-PSS variants (RS256, RS384, RS512, PS256, PS384, PS512), as defined in RFC 7518 (JSON Web Algorithms). Choose HMAC for single-service setups; choose RSA for distributed systems where services verify tokens without sharing the signing key.

Algorithm	Family	Key Type	Padding	Recommended Use
HS256	HMAC	Shared secret	—	Default for single-service auth
HS384	HMAC	Shared secret	—	Stronger hash for compliance requirements
HS512	HMAC	Shared secret	—	Maximum HMAC strength
RS256	RSA	Key pair	PKCS#1 v1.5	Widely supported; use in distributed systems
RS384	RSA	Key pair	PKCS#1 v1.5	Longer hash for RS family
RS512	RSA	Key pair	PKCS#1 v1.5	Maximum RS strength
PS256	RSA-PSS	Key pair	PSS (probabilistic)	Preferred over RS256 for new implementations
PS384	RSA-PSS	Key pair	PSS (probabilistic)	—
PS512	RSA-PSS	Key pair	PSS (probabilistic)	—

HMAC (symmetric), HS256, HS384, HS512

HMAC algorithms (defined in RFC 2104) use one shared secret for both signing and verification. Both the token issuer and every service that verifies tokens must hold the same secret.

HS256: HMAC with SHA-256. The most common JWT signing algorithm across the ecosystem. Minimum recommended secret length: 256 bits (32 bytes).
HS384: HMAC with SHA-384. Use when your security policy requires a larger hash size.
HS512: HMAC with SHA-512. Maximum HMAC strength for high-compliance environments.

RSA and RSA-PSS (asymmetric), RS256, RS384, RS512, PS256, PS384, PS512

RSA algorithms use a key pair. The private key signs; the public key verifies. Verification services only need the public key, which can be published openly via a JWKS endpoint.

RS256 / RS384 / RS512: RSASSA-PKCS1-v1_5 padding. Widely supported across all JWT libraries and platforms.
PS256 / PS384 / PS512: RSASSA-PSS padding. Probabilistic signature scheme with stronger security properties than PKCS#1 v1.5. Recommended over RS variants for new implementations (see RFC 8017).

Minimum RSA key size: 2048 bits; prefer 4096-bit for long-lived signing keys. Use HMAC when one service both issues and verifies tokens. Use RSA or RSA-PSS when independent services need to verify tokens without sharing the signing secret.

JWT Security Vulnerabilities

JWT is secure when implemented correctly. Three vulnerabilities appear consistently in API security audits: the alg:none bypass, algorithm confusion, and weak HMAC secrets. All stem from implementation errors, not flaws in RFC 7519. RFC 8725 (JWT Best Current Practices, IETF) provides the authoritative mitigation guidance.

The alg:none attack

An attacker modifies the token header to set "alg": "none", then removes the signature segment. If the server accepts the alg field from the token header without validation, it skips signature verification entirely and trusts the unsigned token.

Always whitelist accepted algorithms server-side. Never let the token header determine which algorithm to use when you encode or verify, derive it from your own configuration. Every major JWT library has an explicit algorithms parameter, pass it. Example: jwt.verify(token, secret, {'{'} algorithms: ['HS256'] {'}'})

Algorithm confusion (RS256 to HS256)

If a server uses an RSA public key to verify tokens but does not enforce alg, an attacker can change the header to "alg": "HS256" and sign the token using the public key as the HMAC secret. The server then treats the public key as a shared HMAC secret and accepts the forged token.

Enforce the expected algorithm server-side. Never use the same key material for multiple algorithm families. Explicitly configure your library to accept only RS256 or PS256 when using RSA keys.

Weak HMAC secrets

HS256 tokens signed with short or guessable secrets can be brute-forced offline. An attacker who intercepts a valid token can run dictionary or rainbow-table attacks against the signature without any server interaction. Common weak secrets include "secret", "password", or application names.

Use the built-in secret generator on this page to produce a cryptographically random 256-bit (or longer) key. Rotate the secret immediately on any suspected exposure.

Missing claim validation

A valid signature proves the token was issued by a known party, it does not prove the token is appropriate for the current request. Failing to validate exp (expiry), aud (audience), or iss (issuer) allows attackers to replay expired tokens, use tokens issued for a different service, or use tokens from an untrusted issuer.

Always validate exp to reject expired tokens. Validate aud to ensure the token was issued for your specific service. Validate iss to reject tokens from unexpected issuers. Most JWT libraries handle these checks automatically if you pass the expected values in the verification options.

JWT vs Session-Based Authentication

JWTs are stateless, all session data is encoded in the token. Session-based authentication stores session data server-side and gives the client only a session ID. JWTs scale better horizontally; sessions support instant revocation.

Feature	JWT (Stateless)	Session-Based (Stateful)
Where state is stored	Inside the token (client-side)	Server-side (database or cache)
Scalability	Horizontal, no shared session store	Requires shared session store in multi-server setups
Revocation	Cannot revoke before expiry without a denylist	Immediate, delete the session record
Token size	Larger (~200–500 bytes typical)	Small session ID (~20–40 bytes)
Cross-domain / API use	Easy, standard Bearer header	Requires cookie sharing configuration
Microservices	Ideal, each service verifies locally	Each service must query the session store
Sensitive data in token	Not encrypted by default (use JWE)	Never exposed to client
Best for	APIs, microservices, mobile apps, SSO	Traditional server-rendered web apps

Choose JWT for distributed APIs, microservices, mobile applications, single sign-on (SSO), and any architecture where multiple independent services need to verify tokens without sharing a session store.

Choose sessions for applications requiring immediate token revocation (financial systems, admin tools), traditional server-rendered web apps, or systems where token size is a constraint.

Privacy & Security

Runs entirely in your browser.All encoding, decoding, verification, and key generation happen client-side via the Web Crypto API and JavaScript. Whether you encode a new token or decode an existing one, no data is sent to any server. Like all tools in our Security toolkit , this tool is fully client-side.
Nothing is stored or logged.No record is kept of any token, secret, or payload you enter.
Encoded is not encrypted.JWT payloads (JWS) are Base64URL-encoded, readable by anyone with the token. The digital signature makes the payload tamper-proof but not private. For tokens that must carry sensitive data, use JWE (JSON Web Encryption, RFC 7516) instead. This tool handles JWS only.
Decoding is not authentication.Reading a token's contents does not prove the token is valid or trustworthy. Always verify the signature, and validate exp, aud, and iss, before acting on any claim in production.
Treat signing keys like passwords.Use the generator here for a cryptographically random key at the correct length. Store it in an environment variable or a dedicated secrets manager. Rotate it if you suspect exposure. Never commit it to version control.

JWT Decoder & Encoder

Decode JWT

Encode JWT

Verify JWT signature

JWT secret key generator

What Is a JWT Decoder?

How to Use This Tool

Decode a JWT

Encode a JWT

Verify a JWT Signature

Generate a Secret Key

How to Read Your Results

Decoded header

Decoded payload

Signature verification result

JWT Token Structure

Header

Payload

Signature

Common JWT Claims

Supported Signing Algorithms

HMAC (symmetric), HS256, HS384, HS512

RSA and RSA-PSS (asymmetric), RS256, RS384, RS512, PS256, PS384, PS512

JWT Security Vulnerabilities

The alg:none attack

Algorithm confusion (RS256 to HS256)

Weak HMAC secrets

Missing claim validation

JWT vs Session-Based Authentication

Privacy & Security

Related Security Tools

Frequently Asked Questions

What is a JWT?

What does JWT stand for?

Is it safe to decode JWTs online?

What are the parts of a JWT?

Why would I decode a JWT?

Why would I encode a JWT?

What is signature verification and why does it matter?

What is the difference between HS256 and RS256?

What does "jwt expired" mean?

What is a JWT secret key?

What is the difference between JWT and OAuth?

What is a JWKS endpoint?

What is JWE?

What does "audiences in jwt are not allowed" mean?