A short history of Open Badges, from Mozilla to verifiable credentials

A badge issued today might be an Open Badges 2.0 assertion, a 2.1 badge that moves through Badge Connect, or a 3.0 verifiable credential. The icon does not tell you which. This history matters when you need to move old badges between platforms or work out why a validator rejects an otherwise familiar-looking file.

Open the timeline at full size if you are reading on a phone.

2011 to 2013: Mozilla makes learning portable

Mozilla's early Badges project, supported by the MacArthur-funded digital learning work, asked a useful question: how can someone show learning that happened outside a degree programme? Its answer combined an issuer's claim, a recipient, criteria, and an image a person could share. The Mozilla Backpack gave recipients a way to gather badges from multiple issuers in one place.

The Open Badges 1.0 specification appeared in 2013. Baking a badge into an image meant a PNG could carry machine-readable badge data as well as the artwork. A verifier could extract the embedded assertion and follow it back to the issuer. That solved a distribution problem: a badge was no longer just an entry in one course platform.

It did not solve the harder question of whether "completed" meant attended, submitted work, or passed an assessment. That judgement still depends on what the issuer wrote in the criteria. The issue was visible from the first wave of badges and remains visible today.

Open the baked-image diagram at full size.

This packaging explains a problem that has outlived the original Backpack. When a recipient saves a social-media preview or takes a screenshot, the visible picture may survive while the assertion does not. Even an original PNG was not a guarantee that the issuer would keep its referenced URL online forever. The user-friendly distribution layer and the verification dependencies had to be managed separately.

2017 to 2018: stewardship and a stronger 2.0 format

The Badge Alliance helped grow the community beyond Mozilla. IMS Global (now 1EdTech) took stewardship of the standard in 2017, bringing specification and certification processes used across education technology. Organisations could ask vendors which version they supported and whether implementations conformed, instead of treating every badge platform's export as interchangeable.

Open Badges 2.0 reached final release on 12 April 2018. A typical 2.0 badge consists of an Assertion about a recipient, a BadgeClass describing the achievement, and an issuer Profile. Version 2.0 also formalised endorsements, allowing third parties to make explicit claims about an issuer or achievement.

Two verification patterns matter here. A hosted assertion is fetched from the issuer; if the server or domain disappears, verifying the old claim becomes difficult. A signed assertion uses a JWS signature, so it can be checked without relying on the assertion URL still serving the same content. It still depends on a usable trust and key-resolution path. Signed 2.0 badges existed; it would be wrong to say signatures began with 3.0.

Open the hosted-versus-signed comparison at full size.

If you are responsible for old badges, identify the actual mode instead of inferring it from the .png extension. Test a hosted assertion from outside your network and check whether the linked BadgeClass and Profile still resolve. For a signed badge, retain what a verifier needs to obtain and trust the appropriate issuer key. A domain renewal or platform shutdown can disrupt either route in different ways; download a representative example before you move anything.

2019 to 2023: verifiable credentials and Badge Connect

The W3C published the Verifiable Credentials Data Model 1.0 in 2019 and version 1.1 in 2022. These describe a common structure for claims about people or things, not just badges. That wider model gave Open Badges a path into credential wallets and verification tooling built for other use cases. A common data model does not mean every wallet automatically accepts every badge or proof method.

Meanwhile, Open Badges 2.1 was issued in final form on 27 November 2023. Its headline addition was Badge Connect, an API for recipients to move their 2.x assertions between platforms. It addressed portability between services, not a wholesale rewrite of the assertion format. If your issuing platform says "supports 2.1," ask whether it implements the receiving and sharing flows you need, rather than assuming your old badge has become a 3.0 credential.

Open the Badge Connect flow at full size.

The flow uses authorisation between a provider holding badges and a consumer receiving them. That distinction matters in procurement. Ask whether the vendor is the provider, the consumer, or both; test a recipient exporting a badge out of the system, not just importing one in. Check what happens when the learner loses access to an institutional login. An API checkbox on a sales sheet is not evidence that an alumnus can retrieve a credential after graduation.

2024: Open Badges 3.0 changes the document

The Open Badges 3.0 specification records a candidate release in July 2022 and its final 1.0 release on 27 May 2024. A 3.0 badge is an AchievementCredential, built on the W3C verifiable credentials model. The achievement and its criteria sit inside the credential subject. The 2.x Assertion/BadgeClass/Profile structure is not the 3.0 credential format.

The new model makes a cryptographic proof central: a signed token or an embedded data-integrity proof lets a verifier check that the credential has not been altered, subject to resolving the issuer's key and using a supported proof method. It also provides a way for an issuer to publish status, so a verifier can check whether a credential has been revoked or suspended when status is present. A signature alone does not tell you whether the assessment was rigorous or the issuer deserves trust.

Open the format comparison at full size if the labels are too small on your screen.

Do not "upgrade" an old PNG by copying its picture into a new template. The issuer has to decide whether it can legitimately reissue the achievement, map the old criteria to the new claim, identify the holder appropriately, and sign a new credential. Keep the original issuance date and historical requirements distinguishable from the date of reissue. A wallet import and a reissued credential are different operations.

2025 to 2026: the surrounding standards keep moving

The W3C Verifiable Credentials Data Model 2.0 became a Recommendation in May 2025. "VC 1.1" and "VC 2.0" describe the underlying VC profile, not Open Badges 1.1 and 2.0. An Open Badges 3.0 credential can be checked against the supported VC profiles; always read both labels in a verifier report. This distinction explains why "Open Badge 3.0 / VC 1.1" is not a contradiction.

Open the two-version guide at full size.

For a real file, inspect its declared types and contexts rather than its filename. A JSON export can hold a 2.x assertion or a 3.0 credential, and an image can carry a baked version of either. Record the badge version and, for 3.0, the VC profile and proof format. If two systems claim to support 3.0 but cannot exchange files, compare those details first. Shared vocabulary does not ensure they support the same signature suite or wallet flow.

Which later revisions affect old badges?

There have also been maintenance revisions to 3.0 since its 2024 final release. The revision history in the specification records a 2025 deprecation of the older VCRL status approach in favour of the W3C Bitstring Status List, followed by updates to examples using BitstringStatusListEntry in April 2026. A June 2026 revision added endorsementJwt to the JSON-LD context, relevant to implementers carrying endorsements as signed tokens. Deprecation is guidance for new implementations; it does not prove that every previously issued credential has ceased to work. For a platform migration, inventory the status mechanisms used by existing badges, test endorsed examples if you issue them, and verify old credentials before switching off any endpoint.

Make a small compatibility set before updating your issuer: an active badge, an expired badge, a revoked one, a badge with an endorsement if you use those, and a credential with restricted evidence. Store the expected result for each. After a status-list or context update, run that same set through an independent verifier. A change to status infrastructure should be tested with the oldest still-valid issued credential, not only a brand-new sample created on the updated platform.

How to handle a badge from each era

• You have a 1.x or 2.x badge: find the original assertion or baked file, identify whether it is hosted or signed, and use a validator that explicitly supports that version. If it is hosted, keep the issuer URL and its dependencies alive. This site's validator targets Open Badges 3.0; an older format failing here is not proof of forgery.
• You have a 3.0 credential: check its proof, issuer, dates, status if provided, and achievement criteria. For the actual screens, use the validator walkthrough.
• You are migrating an issuing programme: export representative examples, including revoked and expired badges; record versions and proof types; test imports and independent verification; keep old links and status infrastructure working or communicate clearly when they will stop. Do not assume a pretty image contains a portable credential.

For the authoritative format details, start with Open Badges 2.1, Open Badges 3.0, and the W3C VC 2.0 data model. They answer different questions: how older badges travel, what a current badge contains, and how the underlying credential model works.