Every Open Badge
deserves a little
certainty.

The validator could read the credential and its required checks passed at the time of the request. Review the individual checks and any warnings. A valid result does not endorse the issuer or prove that the recipient actually completed the activity described in the badge.

Upload a baked PNG or SVG badge, a JSON or JSON-LD verifiable credential, a .vc file or a compact JWT. Individual uploads must be 5 MB or smaller. URLs may point to a credential or badge resource; remote input is limited to 10 MB, five redirects and a ten-second fetch timeout. A PDF or screenshot of a badge is not a verifiable credential.

This validator is designed for Open Badges 3.0 verifiable credentials, with compatibility settings for some VC 1.1 credentials. Open Badges 2.0 assertions use a different data model; do not interpret a failed 3.0 check as proof that a 2.0 badge is counterfeit.

No issuer allowlist is used. The same format and proof checks apply to credentials from any platform that produces compatible credentials. Examples of issuers and platforms include Certifier, Credly, Accredible, Parchment Digital Badges and Open Badge Factory. Being listed here is not a guarantee that every badge they issue uses the same format or will pass validation.

Passed means the named check succeeded. Failed means the check found an error, which is reported with a code and message. Skipped means the check could not run or did not apply to that credential; it is not the same as passed. Read warnings as well before relying on a result.

These errors happen before a credential can be verified. A PNG or SVG copied from a webpage may contain only the artwork, not the embedded credential. Download the original export from the issuer or paste the hosted credential URL. An unsupported format may be a PDF, screenshot or ordinary webpage.

A failed proof can indicate altered content, a missing key, or an unsupported signing method. A revoked, suspended or expired credential cannot be treated as currently valid. Open the detailed result, record the error code and ask the issuer for a fresh credential or clarification; do not change the credential yourself.

A credential can refer to external JSON-LD contexts, issuer keys, status lists and evidence. To verify those claims, the validator may fetch linked resources. Those hosts may see the requests. Network failures or inaccessible issuer resources can prevent a complete result even when the badge file is intact.

Try another browser, retry with the original file rather than a URL, or use the hosted URL instead of the file. If the service still returns no result, send us the format, the URL domain if it is public, and the approximate time of the attempt through the contact form. Do not send private credentials through the contact form.

No application database or file store keeps your submitted credential. The service processes it for the validation request and returns a report. Hosting providers can retain ordinary security and access logs; linked issuer hosts can see validation requests. If you choose to contact us, your message is delivered to our team by email so we can respond.

The blog has guides to the standards and common failures. For a reproducible problem, use the contact form and include the displayed check name, error code, input format and expected outcome. The published Open Badges and W3C specifications are the primary sources for implementers.