Verify an Open Badge in seconds

It takes an Open Badge and tells you whether the credential still holds up. Upload the file or paste the address it lives at, and the result comes back in a few seconds with every check listed separately.

A green result means the document parsed, matched the schema for its credential type, carried a signature that verified against the issuer key, and was neither revoked nor outside its validity window at the moment you asked. A red result tells you which of those failed and gives you the code to quote when you contact the issuer.

Baked PNG and SVG images, JSON and JSON-LD credential documents, verifiable credential files, and compact VC-JWT tokens. Uploads are capped at 5 MB, which is far more than any real badge needs.

If you paste a URL instead, anything that returns one of those formats works, including hosted credential pages and API endpoints. The fetch stops at 10 MB, follows at most five redirects, and gives up after ten seconds.

The pipeline targets Open Badges 3.0, which is built on the W3C Verifiable Credentials data model. Credentials issued against the VC 1.1 model are accepted in a compatibility mode, since several platforms still produce them.

A 2.0 assertion uses an older, different structure. You can still drop one in: the validator will read it, and report that the document is not an Open Badges 3.0 credential rather than pretending otherwise.

Any platform that follows the specification. The validator has no vendor list inside it and no allow list: it reads the credential, resolves the contexts it declares, and verifies the proof it carries. Where the badge came from makes no difference to the outcome.

In practice we see credentials from Credly, Accredible, Badgr, Canvas Credentials, Open Badge Factory, Sertifier, Virtualbadge.io, and BCdiploma, along with plenty of in-house issuing systems. 1EdTech publishes the list of products that passed formal conformance testing, which is the right place to check before buying.

Read the code next to the failing check first. An input code means the validator never got a credential out of the file, which is usually a problem with the copy you have rather than with the badge itself. A credential code means a real credential was read and something in it did not hold up.

The most common case by far is a badge image saved from a browser or a chat app. Those copies keep the picture and lose the data baked inside it, so the result is a missing baked payload. Go back to the issuer email or the hosted badge page and use the original file or the URL.

A failed proof is different and worth taking seriously. It means the document no longer matches the signature over it, so either the content was edited after issuing or it was signed with a key that does not belong to the issuer in the credential.

That is a bug on our side and we want to hear about it. It usually means the request timed out while fetching something the credential depends on, such as a context file or a status list on a slow host.

Try the file upload instead of the URL, or the URL instead of the file. If it still stalls, send us the badge through the contact form and we will look at the trace.

No. The credential is processed in memory for the length of the request and dropped when the response is sent. There is no database behind this form, no file storage, and no account to create.

We do not run advertising or analytics trackers on the validation page, so there is no profile to build and nothing to opt out of. The one network activity worth knowing about is that verifying a credential means fetching what it points at, so the hosts named inside the badge can see a request arrive.

No. This checks a credential against the published specifications; it is not a conformance certification programme. 1EdTech runs that programme and publishes which products have passed it.

What a green result tells you is concrete: the document is well formed, matches the schema for its type, carries a proof that verifies, and is not revoked or expired. That is enough for a recruiter or an admissions officer to act on. It is not a substitute for formal certification if you are building an issuing product.

A badge is a set of references. The @context files define what its terms mean, the issuer profile says who issued it, the verification method holds the public key, and the status list says whether it is still valid. All of those live somewhere else.

Checking only the local document would tell you that the JSON is tidy and nothing more. Following the references is what turns a tidy document into evidence.

The two endpoints behind this page accept POST requests: one takes a multipart upload in a field named file, the other takes a JSON body with a url property. Both return the full report, including the per check status array and every error and warning with its code and path.

It is fine for occasional use and for wiring a check into an internal tool. If you need volume, a service level, or batch processing, write to us first so we can talk about it rather than discovering your traffic by surprise.

An error means the credential failed a check the specification requires. A warning means something is unusual but allowed, such as an optional field with an odd value or an image link that did not resolve while everything else verified.

Warnings are worth reading before you make a decision, but a credential with warnings and no errors is still valid.

There is no paid tier, no credit counter, and no sign up. Free checks make it easier to spot fake credentials, so anyone holding a badge can verify it without paying.

The validator applies the same published checks to every issuer. Where a badge came from does not change the result.

Use the contact form. Tell us what you uploaded, what you expected, and which code came back, and we will reply to the address you give us.

If a credential is confidential, describe the shape of the problem instead of attaching it. The codes and check names on the result panel are usually enough for us to reproduce it.