Free tool
Open Badges validator
Check an Open Badges 2.0 assertion or a 3.0 verifiable credential. Paste the JSON, upload a baked badge or enter a URL, and see, field by field, what the specification expects and what your badge is missing.
Built for the open standards
Both versions
It tells 2.0 assertions from 3.0 verifiable credentials and checks each against its own specification.
Stays in your browser
Your badge is read on your own machine. Nothing is uploaded, stored or logged.
Reads baked badges
Drop in a PNG or SVG with the badge baked in, and it pulls the assertion out for you.
How it works
How to validate an Open Badge, in three steps
- 01
Add your badge
Paste the JSON or signed JWS of an assertion or credential, drop in a baked PNG or SVG badge image, or enter the URL where the badge is hosted.
- 02
Read the report
The validator finds the version, 2.0 or 3.0, and checks every field the specification asks for, including the BadgeClass and Issuer a 2.0 badge links to. Each result names its field.
- 03
Fix and check again
Errors break the badge, warnings are worth a look. Fix them in your issuing tool, paste the new JSON and run it again.
What it checks
Every field the specification asks for, in both versions
The validator reads the @context and type to tell the version, then runs that version's rules.
Open Badges 2.0
Assertions, BadgeClasses and Issuer profiles, embedded or linked.
- The https://w3id.org/openbadges/v2 context
- Assertion id, recipient, badge, verification and issuedOn
- Recipient type, identity and hashed flag
- Hashed identities in the sha256$… form
- Hosted or signed (JWS) verification
- BadgeClass name, description, image, criteria and issuer
- Issuer id, name, url and email
- Linked BadgeClass and Issuer, fetched and checked
- ISO 8601 dates, expiry and revocation
Open Badges 3.0
OpenBadgeCredential and AchievementCredential, W3C Verifiable Credentials.
- The W3C Verifiable Credentials context first, Open Badges 3.0 second
- VerifiableCredential and OpenBadgeCredential types
- Credential id, issuer, validFrom and credentialSubject
- Issuer Profile id, type, name, url and email
- validFrom and validUntil (and the VC 1.1 names)
- Subject id or identifier, and its Achievement
- Achievement id, name, description and criteria
- Embedded proof or VC-JWT, credentialStatus and credentialSchema
- EndorsementCredential, Achievement and Profile files
Common errors
Open Badges errors, and how to fix them
The problems the validator finds most often, in the words it reports them.
- Missing "verification"
- An Open Badges 2.0 assertion must say how to confirm it. Add "verification": { "type": "hosted" } and host the assertion at its id URL, or sign it and use "signed".
- "hashed" is true, but the identity is not a hash like "sha256$…"
- When "hashed" is true, the identity is the algorithm, a dollar sign, then the hex hash of the email plus the salt. A plain email there means "hashed" should be false.
- "issuedOn" should be an ISO 8601 date-time
- Write dates like 2026-01-31T00:00:00Z. A date such as 31/01/2026 or a Unix timestamp will fail in most readers.
- "@context" must include the W3C Verifiable Credentials context
- An Open Badges 3.0 credential is a W3C Verifiable Credential. Put https://www.w3.org/ns/credentials/v2 first in "@context", then the Open Badges 3.0 context.
- "issuanceDate" is the VC 1.1 name
- Verifiable Credentials 2.0 renamed "issuanceDate" to "validFrom" and "expirationDate" to "validUntil". Rename them to match the current Open Badges 3.0 context.
- "credentialSubject" is missing "achievement"
- Every Open Badges 3.0 credential names what was earned. Add an "achievement" with a type of "Achievement", an id, a name and criteria.
- The subject needs an "id" or at least one "identifier"
- An Open Badges 3.0 credential must say who earned it. Give credentialSubject an "id" (like a did:) or an "identifier" list with a hashed email.
- Could not fetch that URL
- Many badge hosts block requests from other websites. Open the link in a new tab, copy the JSON and paste it into the validator instead.
2.0 vs 3.0
Open Badges 2.0 and 3.0, side by side
Open Badges 3.0 rebuilds the badge as a W3C Verifiable Credential. The same ideas carry new names.
| Open Badges 2.0 | Open Badges 3.0 | |
|---|---|---|
| Data model | Open Badges JSON-LD | W3C Verifiable Credential |
| Main object | Assertion | OpenBadgeCredential |
| What was earned | BadgeClass | Achievement |
| Issued date | issuedOn | validFrom |
| Expiry | expires | validUntil |
| Verification | Hosted URL or signed JWS | Embedded proof (Data Integrity or JWT) |
| Revocation | revoked flag or revocation list | credentialStatus |
FAQ
Validator questions, answered
Issuing badges yourself? Hyperstack issues Open Badges 2.0 on every plan and signed Open Badges 3.0 on selected plans.
See digital badgesOpen the Open Badges validator, then paste the badge JSON, upload the baked badge image or enter its URL. The validator tells whether it is Open Badges 2.0 or 3.0 and lists every error and warning, field by field.
Yes. It is free with no sign-up and no limit on how many badges you check.
No. The validator runs in your browser. The badge JSON and images you add are read on your own machine and are not sent to Hyperstack or stored. When a badge is hosted, or links to its BadgeClass and Issuer, your browser fetches those files straight from the issuer.
Yes. It checks Open Badges 3.0 OpenBadgeCredential and AchievementCredential documents, which are W3C Verifiable Credentials, as well as Open Badges 2.0 assertions, BadgeClasses and Issuer profiles.
Yes. Drop in a PNG or SVG badge with an Open Badges 2.0 assertion or a 3.0 credential baked in, and the validator pulls it out and checks it. If the image only holds a link to a hosted badge, it fetches that link.
Yes. Paste or upload a signed Open Badges 2.0 assertion (a JWS) or an Open Badges 3.0 VC-JWT, and the validator decodes it and checks the badge inside. It also checks embedded Data Integrity proofs for the fields they need.
No. It checks the structure and every field the specification asks for, follows the BadgeClass and Issuer links of 2.0 badges, and reports whether a proof is present and complete. It does not verify the cryptographic signature itself.
No. 1EdTech, the body behind Open Badges, runs its own conformance tools for certification. This validator is a quick, readable field-by-field check for issuers, developers and earners. Use it to find problems fast, and use 1EdTech conformance testing for formal certification.
Yes, if the platform exports Open Badges. Download the baked badge image or copy the assertion JSON from the platform and add it to the validator.
Warnings point to things that are allowed but worth fixing, like a credential with no name, an issuer with no name, an expired badge or a link the browser could not fetch. The badge can still work, but fixing warnings makes it read cleanly in more wallets and backpacks.
Yes. Add ?url= and the address of a hosted badge to the validator link, for example thehyperstack.com/tools/openbadge-validator?url=https://…, and the page checks that badge when it opens. After a URL check, "Copy a link to this check" gives you the link.
Yes. Every Hyperstack plan issues Open Badges 2.0 certificates and badges, and selected plans issue signed Open Badges 3.0 credentials. Recipients add them to LinkedIn and keep them in a free wallet.
Your next cohort deserves better than a PDF
Set up in minutes, send your first credentials today, and only pay once you grow past 20 recipients a year.
Or open a live sample credential