JSON-LD & Open Badges 3.0 Schema Verifier
Audit JSON-LD `@context` arrays, mandatory claims, and 1EdTech Open Badges 3.0 achievement specs 100% in-browser.
What this tool does
It runs a twelve-point structural audit on a JSON-LD verifiable credential — the payload format used by W3C Verifiable Credentials 2.0 and 1EdTech Open Badges 3.0 badges. Paste a credential and each check reports pass or fail with the value it found: the JSON parses to an object; @context is defined and includes the W3C credentials namespace; id is a qualified URI; type contains VerifiableCredential plus a profile type such as OpenBadgeCredential; the issuer is present with a recognized identifier scheme; validFrom or issuanceDate is a parseable ISO-8601 timestamp; credentialSubject exists and its holder id, if present, is a valid URI; and the proof block carries signature details. A summary badge totals the score.
How to use it
- Paste your credential JSON — or press Load Open Badges 3.0 Sample to see a payload that passes everything.
- Press Run 12-Point Schema Compliance Audit.
- Read the checklist top to bottom. A failing row shows what the audit found where it expected something else — usually the fastest route to the malformed field.
Where your data goes
Nowhere. The audit is plain JavaScript running in this tab: no libraries, no network requests, no storage. The sample credential is embedded in the page itself, and everything you paste is gone when you reload.
Who it's for
Badge and credential issuers debugging why a wallet, validator, or verifier rejects their payload; implementers wiring up Open Badges 3.0 or VC 2.0 issuance who want a structural smoke test before integration; and anyone learning what a verifiable credential is actually required to contain. Where a hosted validator answers with a one-line error, this page gives you the field-by-field breakdown.
Honest limits
- Structure, not cryptography. A 12/12 result means the payload is well-shaped — it does not mean the credential is authentic. No signature is verified here; for SD-JWT-style credentials use the SD-JWT verifier.
- Context URIs are checked for presence, not resolved. The audit does not fetch the documents that
@contextpoints to. - Timestamps are checked for parseability, not against the clock — an expired credential still passes this audit.
- Profiles are audited shallowly: the base VC shape is known here, not every profile's additional required fields.
Questions people ask
Does 12/12 mean my badge will validate everywhere?
No. It means the required base structure is present and well-formed. Real validators apply profile-specific rules on top — Open Badges 3.0 has further requirements around achievement details that this audit checks only for presence, not completeness.
Why did my @context check fail?
The check looks for the W3C credentials namespace URI (v1 or v2) inside the @context array. A payload that lists only the Open Badges context or a custom context fails it — most OB 3.0 credentials carry both the W3C and the OB entries, as the sample shows.
Does the audit tell me whether the credential is expired?
It checks that validFrom or issuanceDate parses as a timestamp. Comparing that timestamp against the current clock is deliberately out of scope — a structurally perfect, long-expired credential still passes.
The rest of the verifiers cluster covers signatures, key formats, and revocation — this page is the structure corner of it.