JWT Decoder & Encoder Online – HS256/HS384/HS512, Verify HMAC, Debug Claims

Decode JWT header and payload, verify HS256/HS384/HS512 signatures with your secret, inspect exp/iat/nbf/iss/sub/aud, and encode new JWTs from JSON—all in the browser. No upload; ideal for API auth debugging and learning RFC 7519.

What is JWT?

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs are commonly used for authentication and secure information exchange in modern web applications and APIs.

A JWT consists of three parts separated by dots: Header.Payload.Signature. Each part is Base64 URL encoded, making it safe for transmission in URLs, HTTP headers, and cookies.

How This JWT Tool Works

This professional JWT tool provides comprehensive encoding, decoding, verification, and analysis capabilities for JSON Web Tokens. Create new JWTs with custom claims or decode existing tokens to inspect their structure and verify signatures.

Key Features:

JWT Encoding: Create JWTs with custom header and payload
JWT Decoding: Automatically decode JWT structure as you paste
HMAC Signature: Generate and verify signatures with HS256/HS384/HS512
Three-Part Visualization: Clear separation of Header, Payload, and Signature
Expiration Checking: Automatic validation of exp, iat, and nbf timestamps
Claims Inspection: Display standard claims (iss, sub, aud, exp, iat, nbf)
Real-time Status: Visual indicators for expired or not-yet-valid tokens
One-Click Copy: Copy header, payload, signature, or generated token with a single click
Client-Side Only: All processing happens in your browser for security

JWT Structure Explained

1. Header

The header typically consists of two parts: the token type (JWT) and the signing algorithm being used (e.g., HS256, RS256).

Example Header:

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

2. Payload

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

Registered Claims: Predefined claims like iss (issuer), exp (expiration), sub (subject), aud (audience)
Public Claims: Custom claims that should be collision-resistant
Private Claims: Custom claims agreed upon between parties

Example Payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022,
  "exp": 1735689600
}

3. Signature

The signature is created by taking the encoded header, encoded payload, a secret (for HMAC) or private key (for RSA/ECDSA), and signing them using the algorithm specified in the header.

Signature Creation (HMAC):

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

Supported Algorithms

HMAC Algorithms (Symmetric) - WASM Compatible

HS256: HMAC with SHA-256 - Most commonly used, requires shared secret
HS384: HMAC with SHA-384 - Stronger hash, requires shared secret
HS512: HMAC with SHA-512 - Strongest HMAC variant, requires shared secret

When to use: Simple authentication scenarios, same secret shared between issuer and verifier. These are the most common algorithms for JWT and work perfectly in browser environments.

Note on RSA/ECDSA Algorithms:

This tool currently supports HMAC algorithms only (HS256, HS384, HS512) for WebAssembly compatibility. RSA (RS256, RS384, RS512) and ECDSA (ES256, ES384) algorithms require native cryptographic libraries that are not available in browser environments.

However, you can still decode JWTs signed with any algorithm - you just won't be able to verify RSA/ECDSA signatures in the browser. The header and payload will be decoded correctly regardless of the algorithm used.

Standard JWT Claims

Registered Claims

iss (Issuer): Identifies who issued the JWT (e.g., 'https://auth.example.com')
sub (Subject): Identifies the subject of the JWT (e.g., user ID '1234567890')
aud (Audience): Identifies the recipients the JWT is intended for
exp (Expiration Time): Unix timestamp after which the JWT must not be accepted
iat (Issued At): Unix timestamp when the JWT was created
nbf (Not Before): Unix timestamp before which the JWT must not be accepted
jti (JWT ID): Unique identifier for the JWT, prevents replay attacks

Common Use Cases

1. API Authentication

JWTs are widely used for API authentication, allowing stateless authentication without session storage on the server.

Workflow:

User logs in with credentials
Server generates JWT with user information
Client includes JWT in Authorization header for subsequent requests
Server verifies JWT signature and checks expiration

2. Single Sign-On (SSO)

JWTs enable SSO by allowing users to authenticate once and access multiple services without re-authentication.

3. Secure Information Exchange

JWTs provide a secure way to transmit information between parties, with signature verification ensuring data integrity.

4. Debugging & Testing

Developers use JWT tools to create test tokens, inspect tokens during development, troubleshoot authentication issues, and verify token structure.

Best Practices

Keep Secrets Secure: Never share HMAC secrets publicly or commit them to version control
Use Strong Secrets: Use long, random secrets (at least 256 bits for HS256)
Set Reasonable Expiration: Short-lived tokens (15-60 minutes) are more secure
Always Verify Signatures: Never trust JWT payload without signature verification
Check Expiration: Always validate exp, iat, and nbf claims
Don't Store Sensitive Data: JWTs are not encrypted - avoid storing passwords or sensitive data
Use HTTPS: Always transmit JWTs over HTTPS to prevent interception
Implement Token Refresh: Use refresh tokens for long-term access
Validate All Claims: Check iss, aud, and other claims beyond just signature
Consider Algorithm Choice: HMAC (HS256/384/512) is sufficient for most use cases and has excellent browser support

Frequently Asked Questions

Q: What is a JWT?

A: A JWT (JSON Web Token, RFC 7519) is a compact string with three Base64URL parts: header, payload, and signature. It is commonly used for API authentication and passing signed claims between systems.

Q: Which signing algorithms does this tool support?

A: This tool supports HMAC-SHA256 (HS256), HMAC-SHA384 (HS384), and HMAC-SHA512 (HS512) for both encoding and signature verification in the browser.

Q: Why can't I verify RS256 or ES256 tokens here?

A: RSA and ECDSA verification requires public-key cryptography beyond this WASM build. You can still decode any JWT to inspect header and payload. Only HMAC secrets can be verified in this tool.

Q: Is the JWT payload encrypted?

A: No. JWT payloads are only Base64URL-encoded, not encrypted. Anyone with the token can read the payload. Do not put secrets in the payload; use HTTPS and treat tokens as bearer credentials.

Q: How do I verify a JWT signature?

A: Paste the token, choose the same HMAC algorithm as in the header, enter the shared secret used to sign the token, and read the verification result. The signing input is header.payload (the first two segments).

Q: Is my JWT or secret uploaded?

A: No. Encoding, decoding, and verification run entirely in your browser. Nothing is sent to CompuTools servers.

Related Tools

File Hash Calculator - Compute cryptographic hashes for files and text in your browser: MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA3, Blake2, and more. Drag-and-drop files, hex/base64 output, side-by-side comparison. Nothing uploaded—runs locally with Web Crypto.
CRC Calculator - Calculate CRC checksums with 100+ algorithms for data integrity verification
TOTP Generator - Generate RFC 6238 TOTP codes from a Base32 secret: SHA-1/SHA-256/SHA-512, 15/30/60s steps, 6 or 8 digits. otpauth:// QR for authenticator apps, verify with time drift tolerance, optional HMAC debug. Client-side only.
TLS Certificate Analyzer - Decode PEM or DER X.509 certificates in the browser: subject/issuer, validity, SAN, key usage, fingerprints, and chain relationships—useful for HTTPS debugging and DevOps. No upload to a backend.

Mode

Encode JWT

HMAC signing

Algorithm

Secret key

Header (JSON)

Payload (JSON)