Encoding & Transport

JWK vs JWKS vs PEM for JWT Verification

A practical guide to JWK, JWKS, and PEM so you can feed the right key material into JWT verification and conversion workflows.

Encrypt Online Editorial TeamPublished April 21, 20264 min read

Encrypt Online guide cover on a sky blue background with the headline "JWK, JWKS and PEM". JWK sits above two staggered metadata strokes, one with a leading field dot.

Many JWT debugging sessions start with a pasted key blob and a vague error. The fastest fix is often not more cryptography; it is recognizing whether you were given one key, a set of keys, or a PEM wrapper for an existing key.

JWT tooling becomes much more useful when JWK and JWKS formats are visible. Format mismatch is one of the most common reasons a token verifier feels broken.

In brief

What it is: A JWK is one JSON key object, a JWKS is a JSON document that contains one or more JWKs, and PEM is a textual container commonly used for key and certificate material.

Why it matters: JWT libraries and identity providers do not all expect the same input. Choosing the right form removes a full class of avoidable verification errors.

Worth knowing: Choose a JWK, JWKS, or PEM form that matches the verifier and the token's alg, key type, and kid.

What each format is trying to solve

JWK is meant to be machine-friendly key material for JOSE workflows. A single RSA or EC public key can be represented as JSON fields like kty, n, e, or crv, x, and y. That makes it easy for a browser or API client to parse, inspect, rotate, and match by kid.

JWKS adds one more layer: it is just a set of JWKs under a keys array. Identity providers publish JWKS documents because they need to rotate keys without forcing every client to hardcode one public key forever. PEM solves a different problem. It wraps binary key or certificate material in a text-safe block that older tooling, OpenSSL, and many verification libraries still expect.

JWK: one key, usually JSON, often public material for JOSE.
JWKS: many keys, used for rotation and publication.
PEM: text armor around DER-encoded key or certificate structures.

Where teams lose time

A library may say it accepts a public key, but what it really means is a PEM-encoded SubjectPublicKeyInfo block. The identity provider, meanwhile, hands you a JWKS URL. Nothing is wrong with the crypto. The formats just live at different layers.

The second time sink is assuming the presence of a certificate chain means you should verify with the certificate block directly. Sometimes that is fine. Sometimes the library wants the extracted public key or the correct JWK chosen by kid. The fastest path is to inspect first, convert second, and only then verify.

Match kid, key type, use, and algorithm when a JWKS contains more than one entry.
Include the JWT header's alg when selecting a compatible key form.
Provide public JWK material to public-key verifiers and keep private parameters in the signing environment.

A practical decision rule

If you have a token and a JWKS document, first match the token header to the correct JWK. If the verifier accepts JWK directly, stop there. If the verifier needs PEM, convert only the selected public key. If all you have is a certificate, inspect whether the certificate chain contains the public key you need and whether the library expects certificate PEM or key PEM.

Use short flows, clear labels, and copy-friendly output to answer one operational question about each key container.

See it in a small example

Notice: This is a JWKS because it has a keys array. You still need to choose one JWK from that array before converting or verifying.

{
  "keys": [
    {
      "kty": "RSA",
      "kid": "2026-04-signing-key",
      "alg": "RS256",
      "use": "sig",
      "n": "...",
      "e": "AQAB"
    }
  ]
}