Proving something quickly
Verification takes seconds and needs no phone call, no email to a registrar, and no account on anyone else's platform. That matters most to the person holding the credential, who is usually the one waiting.
Open Badges 3.0 · W3C Verifiable Credentials
Zigilu turns achievements in your learning platform into signed digital credentials. Anyone can check one in seconds — no account, no login, and no need for us to be online.
Free to verify, for anyone, forever.
Not a picture of an award. A document that carries its own proof.
A digital badge is a small, structured document that says who earned what, who says so, when, and on what evidence. What makes it different from a JPEG of a certificate is that it is signed: the issuer runs the content through a cryptographic key, and the resulting signature travels inside the file.
That signature is what lets a stranger — an employer, a university admissions officer, a licensing board — confirm two things without phoning anyone:
Zigilu issues badges as Open Badges 3.0, the specification published by 1EdTech on 29 May 2024. Version 3.0 is built on the W3C Verifiable Credentials model, which is the same data model governments and banks use for digital identity documents [2]. This is not a private format: any conforming reader can check a Zigilu credential, including tools we do not control and did not write.
The scale is not experimental. A 2023 count by 1EdTech and Credential Engine put the number of Open Badges issued worldwide at 74,780,775, up 73% in two years, across 521,070 distinct badges [1].
What was earned, described in words a human reads, plus the criteria it was assessed against.
Who is making the claim, with a public key anyone can fetch to check the signature.
Who earned it. Zigilu stores a salted hash rather than the plain email address.
When it was issued and, if it applies, when it stops being valid.
An Ed25519 signature over the canonical form of everything above.
Where to check, at any later date, whether the issuer has revoked it.
Because a picture of a signature proves nothing, and even a real digital signature has been broken in practice.
The certificate most institutions still send is a PDF with a scanned signature pasted onto it. It is worth being blunt about what that document actually proves: nothing at all. A scanned signature is an image. Anyone with a PDF editor can change the name, the grade, the date and the institution in about a minute, and the result is indistinguishable from the original, because there was never anything to compare it against.
The usual answer is "then use a properly signed PDF". That is genuinely better — and still not sufficient. In 2021, researchers Christian Mainka, Vladislav Mladenov and Simon Rohlmann of Ruhr University Bochum presented Shadow Attacks at the NDSS Symposium. They showed how to build a PDF that displays one thing when it is signed and a different thing afterwards, without invalidating the signature. In their words, the attacks circumvent all existing countermeasures and break the integrity protection of digitally signed PDFs
. 16 of the 29 PDF readers they tested were vulnerable, including widely used commercial ones [3].
The underlying problem is that PDF is a page-layout format that had signing bolted on. What gets signed and what gets displayed are not the same thing. A verifiable credential is the other way round: the document is the data, the signature covers all of it in a canonical form, and there is no separate rendering layer to disagree with.
| PDF with a scanned signature | PDF with a qualified e-signature | Signed digital credential | |
|---|---|---|---|
| Detects an edited name or grade | No | Usually | Yes |
| Survives the Shadow Attack class [3] | Not applicable | Reader-dependent | Yes |
| A machine can read the achievement | No | No | Yes |
| Can be revoked after it is sent | No | Sometimes | Yes |
| Verifiable without contacting the issuer | No | Yes | Yes |
| Looks like a certificate to a human | Yes | Yes | Yes |
Zigilu can attach a PDF or an image to a credential and sign a digest of that file, so the pretty certificate and the verifiable record stay tied together. You do not have to choose one or the other.
Three problems, one mechanism.
Verification takes seconds and needs no phone call, no email to a registrar, and no account on anyone else's platform. That matters most to the person holding the credential, who is usually the one waiting.
A degree title says very little about what someone can do. A badge carries the criteria it was assessed against, so "completed the course" and "demonstrated the skill" stop looking the same.
Certifications expire, get superseded, or turn out to have been issued in error. A signed credential can be revoked, and the revocation is visible to anyone who checks later.
A caution worth stating. Digital credentials are often sold on the promise that employers will hire on skills instead of degrees. The evidence for that shift is weaker than the marketing suggests. A Harvard Business School study with the Burning Glass Institute, published in February 2025, looked at more than 11,000 job postings from 2014 to 2023 and found that where companies dropped degree requirements, fewer than 1 in 700 new hires actually benefited [5]. Better credentials make verification cheap and fraud hard. They do not, on their own, change who gets hired.
The mechanism is the same. The reason for wanting it is not.
The registrar's office is usually the bottleneck. Every verification request — from an employer, another institution, a visa process — costs staff time, and the answer is almost always "yes, that person did study here". Signed credentials move that work to the person asking, at no cost to them and no delay for the graduate.
There is a second reason that gets less attention: issuing precise credentials for parts of a programme. A student who completes three of five modules currently leaves with nothing. A badge per module turns partial progress into something they can show.
Two distinct needs. Inward: knowing what your own workforce is actually certified to do, especially where a lapsed certification is a liability — electrical work, food handling, data protection, machinery. Outward: issuing credentials that your customers, partners or franchisees can prove to third parties.
Expiry is the feature that earns its keep here. A safety certification that quietly lapsed is a risk that nobody sees until an inspection. A credential with an expiry date built in makes that visible before it becomes a problem.
This is where document fraud stops being an inconvenience. In January 2023, a US federal action known as Operation Nightingale uncovered the distribution of more than 7,600 fraudulent nursing diplomas and transcripts from accredited Florida schools. Buyers used them to sit the national licensing exam; those who passed went on to work as nurses. Thirty defendants were charged and convicted in the first phase; a second phase charged twelve more in September 2025 [4].
Paper credentials failed there because verification was expensive and nobody did it at scale. Machine-verifiable credentials change the economics: checking becomes cheap enough to check everyone, every time.
Europe has already taken the regulatory step. European Digital Credentials for Learning must carry an advanced or qualified electronic seal under the eIDAS Regulation (EU) No 910/2014 — the digital equivalent of an institution's stamp [6].
Being specific about the threats is the only way to be honest about the defences.
The attack: produce a document that claims an achievement that was never earned.
What stops it: the signature. Producing a valid one requires the issuer's private key, which never leaves the issuer's server. A forged credential fails verification immediately, and it fails for everyone who checks, not just for people who know what to look for.
The attack: take a genuine credential and change the name, the grade, or the date. This is by far the most common form of credential fraud, because it starts from something authentic.
What stops it: the signature covers a canonical form of the entire document, so any change breaks it. Our validator goes one step further: when you upload a badge image, it compares your copy against the one the issuer holds and reports ALTERED if they differ — even though the identifier inside is still perfectly valid. Checking only the identifier would have said the credential was fine.
The attack: set up something that looks like the university's credential system and issue convincing credentials from it.
What stops it: the issuer's public key is published at a stable address, and the credential names the issuer it belongs to. A credential signed by a different key does not verify against that issuer, however convincing the branding is. This is also why you should link to verification from your own official domain — see the practices below.
The attack: take a real credential belonging to a real person and present it as your own.
What stops it: partly. The credential binds to a recipient identifier, so a verifier can confirm the badge belongs to a specific email address. But no credential system can confirm that the person in front of you controls that address — that is an identity check, and it is a separate job. We would rather say this plainly than imply a guarantee we cannot make.
The attack: keep using a certification after it was revoked or expired.
What stops it: a revocation list, published as a compact bitstring so that checking one credential does not reveal which one you were interested in. Verification checks it every time.
A credential is a public document by design — that is the point of it. So the less personal data inside it, the better. Zigilu stores a salted, peppered hash of the recipient's email address rather than the address itself. A verifier who already knows the address can confirm the match; someone who finds the credential cannot work backwards to the person. Verification requests are not tied to a visitor account, because there is no visitor account.
Most credential programmes fail for organisational reasons, not technical ones.
Write the criteria down and publish them. "Attended a webinar" and "demonstrated a competency" are both legitimate, but a recipient and a verifier must be able to tell which one they are looking at. Vague criteria are the fastest way to make your credentials worthless.
A verification link on the issuing institution's own site is much harder to spoof than one on a third-party platform, because the domain itself is part of the proof. If someone can register a plausible lookalike domain, they can fake your whole credential programme.
Safety, clinical and regulatory certifications usually do. Academic degrees usually do not. Adding an expiry to a degree is not extra rigour; it is a promise to reissue that someone will eventually fail to keep.
Decide who has the authority to revoke, what evidence they need, and how the recipient is told. Discovering that no one owns this decision during an academic integrity case is a bad time to find out.
A credential can travel to places you did not anticipate and can be public for years. Every additional personal field is a liability with no expiry date. Ask what a verifier genuinely needs.
The signing key is the whole system. It should live outside the web root, be readable only by the service account, and never appear in a repository, a backup that leaves the building, or a log file.
Most people have never received a verifiable credential and will not know it is different from a PDF. If you do not explain how to share it, they will screenshot it — and a screenshot has none of the properties you paid for.
Zigilu is a hosted service, like the others. The difference is what happens when a provider stops.
Most digital credentialing is bought as a hosted service, and Zigilu is one too: we run it, you use it. Credly (opens in a new tab), Accredible (opens in a new tab) and Canvas Credentials (opens in a new tab) are well-established platforms in the same category.
So the honest question is not where the software runs. It is this: if the provider goes down, gets acquired, or shuts the product, can the credentials still be verified? On most platforms verification is a page on the provider's system — no provider, no verification. Zigilu is built so the answer stays yes.
How that works. Everything a verifier needs — the credential itself, the issuer's public key, the revocation list — is published as plain static files, served independently of the application. We test this by stopping the application and verifying a credential anyway. And because the format is Open Badges 3.0, those files can be checked by any conforming reader on earth, including software we did not write and do not control.
| Typical hosted platform | Zigilu (managed service) | |
|---|---|---|
| Who operates the service | The provider | We do. There is nothing for you to install |
| Verification if the provider has an outage | Usually stops with the provider | Keeps working. Static files, served independently of the application |
| Verification if the provider disappears entirely | Depends on that provider's wind-down | The credential files remain verifiable by any Open Badges 3.0 reader |
| Format lock-in | Varies. Check the export path before you commit | Open standard end to end, with two independent signatures and a JWT representation |
| Recipient personal data inside the credential | Varies by provider | None in clear. A salted, peppered hash of the email address |
| Recipient needs an account to hold a badge | Usually yes | No |
| Verifier needs an account | Sometimes | Never |
| Support and account management | Included | Included |
| Ready-made LMS integrations | Yes, and this is a real advantage | Not yet. We build the integration with you |
| Recipient wallet and sharing tools | Yes | No |
| Time to first credential | Same day | An API integration with your platform |
Assessed against publicly available documentation on 6 August 2026. Vendors change quickly; check the current position with each of them before you decide. If another platform fits your situation better, use it — the standard is the same either way, and a credential issued by any conforming system is verifiable by any conforming reader.
Choose another platform if you need to be issuing this month, or you want recipient-facing wallet and sharing tools out of the box. Choose Zigilu if the thing that worries you is what happens to your credentials in five years — when the contract, the vendor or the product may not be the same, and the credential still has to prove what it says.
Zigilu
Only what is built and tested. Nothing on this page is a roadmap item.
Every credential carries two independent proofs over the same document — eddsa-jcs-2022 and eddsa-rdfc-2022 — so verifiers that implement either one can check it. Same Ed25519 key, same badge.
Withdrawing a credential flips a bit in a signed W3C Bitstring Status List. Checking one credential does not reveal which one you checked.
The signed credential is baked into the PNG or SVG. Download the image, upload it anywhere, and the proof travels with it.
Attach a PDF certificate and its digest becomes part of the signed document, so the file cannot be swapped for another.
Each achievement can point at the framework and code it maps to, so a credential means the same thing to a system that has never seen it.
The learner's email never appears in the credential, only a salted and peppered hash. It can be matched, not reversed.
Issuance is idempotent. If your platform retries after a timeout, you get the same credential back rather than a second one.
Every write is signed with HMAC-SHA256, bound to a timestamp window and a single-use nonce, and scoped per client.
The files a verifier needs are static and served independently of the application, so verification keeps working during an outage.
The same credential is also served as a compact JWS (application/vc+jwt) from the same URL, for wallets and government systems that speak JOSE. Same identifier, same revocation.
We run our credentials through third-party validators and publish what they say, including what they reject. Interoperability you cannot demonstrate is a claim, not a feature.
Paste an identifier or upload the badge. No account, no login, no charge.
Including the ones with awkward answers.
That depends entirely on your jurisdiction and on what the credential asserts, and anyone who answers this question with a flat "yes" is selling something. What a signed credential gives you is strong technical evidence of origin and integrity. Whether a particular authority accepts that as legal proof is a legal question, not a technical one. In the European Union, credentials that must carry legal weight are expected to use an advanced or qualified electronic seal under eIDAS Regulation (EU) No 910/2014 [6].
This is the right question to ask a supplier, so here is a precise answer rather than a reassuring one. Everything needed to verify a credential — the credential document, the issuer's public key and the revocation list — is published as plain static files, served independently of the application. They are not locked in a database only we can read, and the format is an open standard, so any conforming Open Badges 3.0 reader can check them without our permission and without our servers. We test the weaker version of this regularly: we stop the application and verify a credential anyway.
What that does not settle by itself is who keeps serving those files if the company is gone. That is a contractual question, not a technical one, and it belongs in your agreement with us: ask for the export and continuity terms in writing before you sign. We would rather you ask than assume.
Not without the issuer's private key. The signature is checked against the issuer's published public key, so a credential signed by anything else fails. The realistic attack is not forging the cryptography — it is stealing the key, or persuading someone to issue a genuine credential for an achievement that never happened. Both are organisational problems, which is why key custody and clear issuing criteria matter more than the choice of algorithm.
The validator catches it. Upload a badge whose embedded credential has been altered and the verdict is ALTERED, not VALID — because we compare your copy against the issuer's rather than just trusting the identifier inside it. Checking the identifier alone would report the credential as fine, which is exactly the failure a validator exists to prevent.
No, and neither do verifiers. The credential is a file the recipient owns. There is no wallet to sign up for and no profile to maintain. That is a deliberate trade-off: it also means we do not provide the sharing and portfolio features a hosted platform would.
Not yet. Zigilu is an API, and connecting it to a learning platform is an integration we build with you. We would rather say that here than let you find out after a procurement process. If you need one-click installation this week, a platform with ready-made plugins will get you there faster — and you can still ask us what the integration would involve.
As little as we can manage. The recipient is stored as a salted and peppered hash of their email address rather than the address itself, so a verifier who already knows the address can confirm the match while someone who merely finds the credential cannot recover the person. Everything else in the credential is whatever your platform sends, which is why choosing those fields carefully is one of the practices above.
Yes, at any time, and the revocation is visible to anyone who verifies afterwards. Revocation status is published as a bitstring status list, which means checking one credential does not disclose which credential you were checking.
Mostly the words your sector uses. Technically they are the same object: a signed statement that a named party earned a defined achievement. "Micro-credential" usually implies something smaller than a qualification and assessed against explicit criteria; "certificate" often implies a document meant to be printed. Zigilu issues one kind of thing and lets you call it what your audience calls it.
Open Badges 3.0 is an open specification, so credentials from any conforming issuer can be read by any conforming verifier. Our validator reads the credential embedded in a badge image and tells you what it finds. It can only confirm validity against the issuer that signed it, so a credential from another issuer is checked against that issuer, not against us.
Verification is free for anyone, forever — that is not a promotion, it is a property of the design, since verification does not require our permission or our servers. For issuing, talk to us: what it costs depends on your volume and how much integration help you need, and quoting a number here without knowing either would be guesswork.
It is built to WCAG 2.1 Level AA and we have tested it, but the claim is our own self-assessment rather than an external audit. The accessibility statement says exactly what was checked, what tools were used, and what we know is still imperfect. If something does not work for you, please tell us — that is the fastest route to it being fixed.
Every figure quoted on this page, with its origin. Checked on 6 August 2026.
Tell us what you need to issue and we will tell you honestly whether this fits.
All fields are required unless marked optional.