HS384 JWT Algorithm

Q: Can I verify an HMAC JWT without knowing the secret?

No. HMAC-family algorithms (HS256, HS384, HS512) are symmetric — the same secret is used to both sign and verify. Without the secret, you can decode the header and payload (they're just base64url-encoded) but cannot verify the signature's authenticity.

Q: How long should my HMAC secret be?

At least as long as the hash output — 32 bytes (256 bits) for HS256, 48 bytes for HS384, 64 bytes for HS512. Generate with Node.js: require('crypto').randomBytes(32).toString('hex'). Never use passwords or guessable strings as JWT secrets.

Q: When should I use HS256 vs RS256?

Use HS256 when all services that verify the token are in your trust boundary and can share the secret securely (e.g., a single backend service). Use RS256 when you need to share the public key with external services (OAuth resource servers, third-party clients) without sharing the signing secret.

HS384 is the SHA-384 variant of HMAC JWT signing. It produces a 384-bit signature — 50% larger than HS256's 256-bit output. The key and trust model are identical to HS256: a single shared secret used by all parties. HS384 sees limited adoption in practice; most systems choose HS256 or HS512.

Family

HMAC

Hash

SHA-384

Key type

symmetric

Performance

Fast (< 0.1ms)

Key Requirements

A shared secret of at least 384 bits (48 bytes) recommended to match the SHA-384 hash output. Keys shorter than 256 bits will be rejected by RFC-compliant libraries.

JWT Header

Every JWT using HS384 has this header (base64url-encoded as the first segment):

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

Code Examples

Node.js — Sign (jose library)

import { SignJWT } from 'jose'

const secret = new TextEncoder().encode(process.env.JWT_SECRET) // 48+ bytes

export async function signToken(payload: Record<string, unknown>) {
  return new SignJWT(payload)
    .setProtectedHeader({ alg: 'HS384' })
    .setIssuedAt()
    .setExpirationTime('2h')
    .sign(secret)
}

Node.js — Verify (jose library)

import { jwtVerify } from 'jose'

const secret = new TextEncoder().encode(process.env.JWT_SECRET)

export async function verifyToken(token: string) {
  const { payload } = await jwtVerify(token, secret, {
    algorithms: ['HS384'],
  })
  return payload
}

Python — PyJWT

import jwt

SECRET = "your-384-bit-secret"  # 48+ bytes

token = jwt.encode({"sub": "1234567890"}, SECRET, algorithm="HS384")
payload = jwt.decode(token, SECRET, algorithms=["HS384"])

When to Use HS384

A middle-ground option when you need more collision resistance than HS256 but not the full weight of HS512. In practice, most applications pick HS256 (adequate for all normal uses) or HS512 (maximum symmetric strength). HS384 is selected mainly by compliance policies that specify SHA-384.

Security Considerations

Same shared-secret trust-model risk as HS256: all verifiers hold the same key. Prefer RS256 or ES256 when cross-service or third-party verification is required.

Related Algorithms

HS256 HS512

Standardised in RFC 7518 §3.2 — JSON Web Algorithms (JWA).

Decode a real JWT

Paste any JWT into the debugger to inspect the header, payload, and verify an HS384 signature.

Open JWT Debugger

Frequently Asked Questions

Can I verify an HMAC JWT without knowing the secret?

No. HMAC-family algorithms (HS256, HS384, HS512) are symmetric — the same secret is used to both sign and verify. Without the secret, you can decode the header and payload (they're just base64url-encoded) but cannot verify the signature's authenticity.

How long should my HMAC secret be?

At least as long as the hash output — 32 bytes (256 bits) for HS256, 48 bytes for HS384, 64 bytes for HS512. Generate with Node.js: require('crypto').randomBytes(32).toString('hex'). Never use passwords or guessable strings as JWT secrets.

When should I use HS256 vs RS256?

Use HS256 when all services that verify the token are in your trust boundary and can share the secret securely (e.g., a single backend service). Use RS256 when you need to share the public key with external services (OAuth resource servers, third-party clients) without sharing the signing secret.