What is a JSON Web Token (JWT)?

If you’ve worked with modern web authentication, you’ve almost certainly encountered JSON Web Tokens. JWTs have become the de facto standard for transmitting authentication and authorization information between parties in a compact, secure, and self-contained way. But what exactly are they, and why have they become so ubiquitous in web development?

A JSON Web Token is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret with the HMAC algorithm or a public/private key pair using RSA or ECDSA.

The beauty of JWTs lies in their stateless nature. Unlike session-based authentication where the server must store session data, JWTs contain all the necessary information within the token itself. This makes them perfect for distributed systems, microservices architectures, and scenarios where scalability is crucial.

Understanding JWT Structure

Every JWT consists of three parts separated by dots (.), which are:

The header typically consists of two parts: the type of token (JWT) and the signing algorithm being used, such as HMAC SHA256 or RSA. For example:

{
  "alg": "HS256",
  "typ": "JWT"
}

This JSON is then Base64URL encoded to form the first part of the JWT.

Payload

The payload contains the claims—statements about an entity (typically the user) and additional data. Claims are categorized into three types:

Registered claims: Predefined claims like iss (issuer), exp (expiration time), sub (subject), and aud (audience)
Public claims: Custom claims defined at your discretion, but should be collision-resistant
Private claims: Custom claims agreed upon between parties

Signature

The signature is used to verify that the sender of the JWT is who it says it is and to ensure the message wasn’t changed along the way. To create the signature, you take the encoded header, encoded payload, a secret, and the algorithm specified in the header.

Common JWT Claims Explained

Understanding the standard claims helps you work more effectively with JWTs:

iss (Issuer): Identifies the principal that issued the JWT. This is typically a URL or identifier of your authentication service.
sub (Subject): Identifies the principal that is the subject of the JWT—usually the user ID or email.
aud (Audience): Identifies the recipients that the JWT is intended for. This prevents tokens meant for one service from being used by another.
exp (Expiration Time): The timestamp after which the JWT must not be accepted. Critical for security!
nbf (Not Before): The timestamp before which the JWT must not be accepted. Useful for issuing tokens that activate later.
iat (Issued At): The timestamp when the JWT was issued. Helps determine the token’s age.
jti (JWT ID): A unique identifier for the JWT. Can be used to prevent replay attacks.

How to Use This JWT Decoder

Our JWT decoder makes inspecting tokens simple and secure:

Paste Your Token: Copy your JWT and paste it into the input area, or drag and drop a file containing the token.
View Decoded Data: The tool automatically decodes your token and displays the header, payload, and signature in separate tabs.
Analyze Claims: The Claims Analysis section shows you relevant claims with human-readable timestamps and expiration status.
Verify Signatures: For HMAC-signed tokens (HS256, HS384, HS512), enter your secret key to verify the signature integrity.
Export Results: Copy individual sections or download the complete decoded token as a JSON file.

JWT Security Best Practices

Working with JWTs requires understanding security implications:

Never Trust Client-Side Validation Alone

While this tool verifies signatures client-side, always perform validation on your server. Client-side checks can be bypassed.

Keep Secrets Secure

Your HMAC secret or RSA private key should never be exposed in frontend code. Store them securely in environment variables and only use them server-side.

Use Short Expiration Times

Short-lived tokens reduce the window of opportunity if a token is compromised. Combine with refresh tokens for better user experience.

Validate All Claims

Don’t just check if a token is valid—verify that the issuer, audience, and other claims match your expectations.

Be Careful with `none` Algorithm

Tokens with "alg": "none" are unsigned. Never accept them in production unless you have a specific, secure reason to do so.

Common JWT Algorithms

Symmetric (HMAC)

HS256: HMAC using SHA-256. Most common for single-service applications.
HS384: HMAC using SHA-384. Stronger security than HS256.
HS512: HMAC using SHA-512. Maximum security for symmetric signing.

Asymmetric (RSA)

RS256: RSASSA-PKCS1-v1_5 using SHA-256. Ideal for microservices where public key verification is needed.
RS384/RS512: Stronger variants using SHA-384 and SHA-512.

Asymmetric (ECDSA)

ES256: ECDSA using P-256 curve and SHA-256. Smaller keys with equivalent security.
ES384/ES512: Using P-384 and P-521 curves respectively.

Privacy and Security

Your data never leaves your browser. All decoding and signature verification happens client-side using JavaScript. We don’t log, store, or transmit your tokens anywhere. This tool is safe to use with production tokens containing sensitive information.

The signature verification uses the Web Crypto API, providing native browser-level cryptographic operations without any external dependencies.

Frequently Asked Questions

Is it safe to decode JWTs in the browser?

Yes! Decoding a JWT is simply Base64 decoding—it reveals the contents but doesn’t compromise security. The security of a JWT comes from its signature, not obscurity. However, be aware that anyone with the token can decode it, which is why you should never put highly sensitive data in JWT payloads.

Can someone create a fake JWT?

Without the secret key (for HMAC) or private key (for RSA/ECDSA), attackers cannot create valid signatures. They can modify the payload, but any proper server-side validation will reject the tampered token.

What happens when a JWT expires?

When the current time exceeds the exp claim, the token is considered expired. Well-implemented systems will reject expired tokens and require the user to obtain a new one, typically through a refresh token flow.

Why is my JWT signature invalid?

Common reasons include: wrong secret key, algorithm mismatch (checking with HS256 when signed with RS256), token corruption during copy/paste, or the token was actually tampered with.

Can I use this tool offline?

Yes! Once loaded, the tool works entirely in your browser without any network requests.

Start Decoding

Scroll up to use the JWT Decoder. Paste your token, explore the claims, and optionally verify the signature—all without your data ever leaving your device.

JWT Decoder