Free JWT verifier · unlimited

Check any seal. Free.

This page checks the ES256 signature in your browser, against our public key. JWT or SD-JWT VC. Nothing you paste is sent to us.

Verification is public and free. You need an account to create credentials — never to check one.

Verify one right now

JWT or SD-JWT VC · checked in this browser only

Runs entirely in your browser with WebCrypto. After the key set loads, we make no further requests — open your network tab and watch.

No credential handy? Tamper flips one character of the payload and re-verifies. One changed byte breaks the signature.

What happens
  1. 1Read the sealheader · payload · signature
  2. 2Find the keykid → published JWKS · ES256
  3. 3Check the signatureECDSA P-256 · WebCrypto, in this browser
  4. 4Resultno request sent to 5arz
Paste a credential, then press Verify signature.

Key set: not loaded yet.

Decoded sealRun a check to see the header and claims.
Header
—
Payload (claims)
—
What a seal proves

Who, what and when.

Who

A verified person

ID and liveness passed. You never see their name or face.

What

One exact action

The seal names what was done. Change it and the check fails.

When

One moment

The time is signed with everything else.

The exact claim

What “offline” means here.

If we went dark tomorrow, every credential we issued would still verify. That’s the only way the proof means anything.

What is true

You fetch the public key set once over HTTPS and cache it. After that, every check is a local signature check.

  • No network call, no round trip
  • No dependency on 5arz being up
  • Nothing you check is visible to us

What is not true

It isn’t magic. The first key fetch needs the internet, and you should refresh the key set to pick up rotations.

A credential also carries an expiry. Checking it is your job — one line.

Why this is the whole product

Most vendors return a score, worth only your trust in the vendor. You can’t audit it, reproduce it, or check it after they’re gone.

We return a signature. It is valid or it isn’t, and anyone with the public key can settle that — without asking us.

How it works

Four steps, once.

  1. Fetch the key set

    GET https://api.5arz.com/.well-known/jwks.json — public, CORS-open, no auth.

  2. Cache it

    In memory, on disk, or in your repo. Refresh daily to pick up rotation. Keys are identified by kid, so old and new coexist — with one exception, below.

  3. Match the kid

    Decode the JWT header and find the key with that kid. The live signing key today is 5arz-oracle-2.

  4. Verify and read the claims

    Standard P-256 / SHA-256, in every language. Then check exp and read what the credential asserts.

One key we cannot publish

Our policy: a retired public key stays in the key set permanently. Rotating a signing key must never stop an already-issued credential from verifying.

There is one exception, and we’d rather you read it here. An earlier key, 5arz-oracle-1, was retired before that policy existed, and its public half was not kept.

Any credential carrying kid: 5arz-oracle-1 cannot be verified — not by you, and not by us. We don’t present that vintage as verifiable. It covers roughly a dozen test credentials from our partner path; none is in production use.

Everything signed since — every credential under 5arz-oracle-2 — is covered by the retention policy, and the key set is built to serve retired keys alongside the live one.

Offline signature verification

Check it in your own code.

Complete and runnable. No 5arz SDK needed — any JWT library can verify a seal. For an SD-JWT VC, verify the part before the first ~.

  • One key: 5arz-oracle-2
  • ES256 signatures
  • No account needed to check
// npm i jose
import { createRemoteJWKSet, jwtVerify } from 'jose';

// Fetched once, then cached in-process and refreshed on rotation.
const JWKS = createRemoteJWKSet(
  new URL('https://api.5arz.com/.well-known/jwks.json'),
  { cacheMaxAge: 86400000 }   // 24h
);

export async function verifySeal(token) {
  const { payload, protectedHeader } = await jwtVerify(token, JWKS, {
    algorithms: ['ES256'],
    issuer: 'https://5arz.com'
  });
  // Signature is valid and exp/nbf were enforced by jwtVerify.
  return { ok: true, kid: protectedHeader.kid, claims: payload };
}

In the Browser tab: the use / key_ops strip is what trips people up. WebCrypto is stricter than the JWKS spec; other libraries handle it for you.

Read the claims

What the claims mean.

A valid signature means authentic and unmodified. What the credential says is in the claims — read them.

ClaimWhat it asserts
issWho signed it. Should be https://5arz.com — pin this, don’t just check the signature.
iat / expWhen it was issued and when it stops being valid. Enforce exp.
subThe subject the proof is about — a session, a task, or a piece of content.
testPresent and true on sandbox credentials. A test credential is not proof of anything. Reject it in production.

Two things a signature does not prove

  • Who the person is. A seal asserts a real human did a specific thing. It isn’t an identity document: no name, no biometric.
  • That nobody copied it. A screen recording is still a copy. What a copier can’t do is produce a valid seal — so theft is provable, not preventable.
Local vs. vendor API

Why not just call an API?

You can — we have one. Here’s what changes when verification is local.

QuestionVendor API checkOffline signature check
Works if the vendor is downNoYes
Works if the vendor is goneNoYes
Vendor sees what you verifyYesNo
LatencyNetwork round tripSub-millisecond, local
Rate limitedUsuallyNo
Costs money at scaleUsuallyFree, unlimited
Auditable by a third partyNoYes

The honest caveat: an offline check can’t know about a revocation issued after your key set was cached. That’s true of every signed credential — it’s why certificates have revocation lists.

Our revocation window: 15 minutes

We publish a W3C Bitstring Status List — one bit per credential in a single cacheable file. You download the whole list, so we never learn which credential you checked.

A revoked credential stops verifying within 15 minutes if you follow our refresh interval, and immediately if you check status live. Lost-device revocation is immediate everywhere: it deletes the key.

We state the window rather than claim zero. No signature-based credential can have a zero window.

FAQ

Questions, answered.

Does verifying a 5arz credential require an API call to 5arz?

No. A 5arz credential is an ES256 JWT signed by a P-256 key. You fetch the public key set once from https://api.5arz.com/.well-known/jwks.json, cache it, and every verification after that is a local signature check on your own hardware. No account, no API key, no network call at verify time.

What happens to my credentials if 5arz shuts down?

Authenticity and expiry keep verifying against public keys you already hold, with no dependency on 5arz being reachable. Revocation status is the one check that needs a published status list; our stated refresh window is 15 minutes.

How fast is offline verification?

An ES256 signature check on a cached key is sub-millisecond on ordinary server hardware. There is no network round trip because there is no network call.

Do I need a 5arz account to verify a credential?

No. Verification is public and free with no account. You only need an account to create credentials.

Issue seals of your own.

Start free. Checking stays free, always.