Open Badges 2.0, explained: how a digital badge carries its own proof.

A digital badge looks like an image. Underneath, a badge that follows the Open Badges standard is a small bundle of structured data: who issued it, what it means, who earned it and how to check it. That data is what makes a badge portable between platforms and verifiable by anyone, long after it was issued.

Open Badges was started by the Mozilla Foundation and is now maintained by 1EdTech, formerly IMS Global. Version 2.0 is the version most badge platforms, wallets and learning systems support today.

The three parts of a badge

Every Open Badge is made of three linked objects.

Issuer

The organisation that awards the badge: its name, website and contact email. A verifier uses this to decide whether they trust the source.

BadgeClass

The achievement itself: a name, a description, an image and the criteria a person had to meet. It can also list the skills or competencies the badge stands for, aligned to a published framework.

Assertion

The record that a specific person earned that badge on a specific date. It names the recipient, usually by a hashed email address, links to the badge class, and says how the assertion can be verified.

What an assertion looks like

Here is a simplified assertion. Real ones carry a few more fields, but the shape is the same.

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://example.org/assertions/9bb5918c",
  "recipient": {
    "type": "email",
    "hashed": true,
    "identity": "sha256$c7ef86405ba71b85acd8e2e95166c4b1"
  },
  "badge": "https://example.org/badges/data-analyst-2",
  "issuedOn": "2026-09-14T10:00:00Z",
  "verification": { "type": "hosted" }
}

Key fields at a glance

How verification works

Open Badges 2.0 supports two methods.

• Hosted verification. The assertion lives at a public URL on the issuer’s domain. A verifier fetches it, checks that the recipient matches, and checks that it has not been revoked or expired.
• Signed verification. The assertion is signed with the issuer’s private key. A verifier checks the signature against the issuer’s public key, so the badge can be validated even when it is passed around as a file.

In both cases, the verifier never has to email the issuer and wait. The badge carries enough information to check itself.

The point of an open standard is that your learners’ achievements outlive any one platform, including yours.

Baking: the badge inside the image

Open Badges also defines “baking”: embedding the assertion inside the badge image file itself, in a PNG or SVG. A baked badge can be uploaded to another platform, which reads the data out of the image and verifies it. This is how a badge moves between wallets without anyone retyping anything.

Why it matters for issuers

1. Portability. Learners can take their badges to any compliant wallet or backpack.
2. Machine-readable skills. Criteria and alignments can be read by hiring and learning systems.
3. Less admin. Verification requests stop landing in your inbox.
4. No lock-in. If you change platforms, badges you have already issued still describe themselves.

What about Open Badges 3.0?

Version 3.0 aligns Open Badges with the W3C Verifiable Credentials data model, the same model used by digital identity wallets. Adoption is growing, but 2.0 remains the most widely supported version. For most issuers today, the practical advice is to issue 2.0 badges from a platform that keeps up with the standard as it evolves.