Certificate verification sounds more technical than it is. In practice it comes down to three pieces — a unique code, a public page and a QR that connects them — and it’s worth understanding each one before deciding how to roll it out at your institution.
Piece 1: a unique code per certificate
When you issue a certificate, the system assigns it its own identifier. It isn’t the participant’s national ID or the course number: it’s a code that exists only for that certificate, for that person, on that training.
Two properties matter more than any others:
- Unique. No two certificates share a code, so a lookup always returns an unambiguous result.
- Non-guessable. If codes were
0001,0002,0003, anyone could walk through your issuances by changing a digit. That’s why long, random identifiers are used.
The code is printed on the certificate itself, usually in the footer, so it stays readable even on a photocopy.
Piece 2: a public verification page
The code on its own is useless if there is nowhere to check it. The second piece is a public web page — no signup, no password — where that code turns into an answer.
When someone opens it, the system looks the code up in the institution’s record and shows what applies:
- Valid certificate. The issuance details appear: participant, course name, date, duration and issuing institution.
- Certificate not found. The code matches no issuance. It may be a typo, or a document that never existed.
The key is where that answer comes from. The page doesn’t read the PDF the person is holding: it queries your institution’s record at that very moment. That’s why an altered document can’t fool the verification — the file will say one thing and the screen another.
Verifying isn’t inspecting the paper more carefully. It’s asking whoever issued it, directly.
Piece 3: the QR code
The QR is simply the link to that page turned into something a camera can read. Nothing more. It doesn’t contain the certificate data or a signature: it contains the address where that data can be looked up.
Its value is that it removes friction. Without a QR, the person verifying has to open a browser, type an address and transcribe a long code without making a mistake. With a QR, they point a phone at the document — printed or on screen — and land straight on the result.
Because the QR is only a link, the code should also appear in writing. If the document is creased, badly printed or arrives as a photocopy of a photocopy, the written code still works.
What the verifier actually sees
It’s worth putting yourself in the shoes of the person doing the lookup: almost always someone in HR reviewing an application, or a supervisor confirming that their team completed mandatory training.
They scan the QR with the phone camera. A page opens carrying your institution’s visual identity. Within a few seconds they can see that the certificate exists and what it corresponds to. They close the tab and get on with their day.
That’s the whole flow. No account created, nobody called, no waiting for an email reply. And on your side, nobody had to handle that request.
Why your own domain matters
Here is a decision that looks minor and isn’t: what address that verification page lives at.
If the link points to a software vendor’s generic portal, the person verifying lands on a page they don’t recognise, carrying a brand that isn’t yours. They have to trust an intermediary they’ve never heard of, and the check that was supposed to reinforce your credibility ends up reinforcing someone else’s.
If the link points to a subdomain of your own — say certificates.yourprovider.cl — three different things happen:
- The check is coherent. The certificate says your institution issued it, and the verification happens at your institution’s address. There is no leap of trust.
- Your brand shows up at the decisive moment. Right when an employer is assessing someone’s training, they see your identity.
- The relationship is yours. If you ever change platforms, certificates already issued keep pointing at a domain you control.
Technically the cost is low: point a subdomain at the verification platform and let it answer with your institution’s identity. It’s a one-time setup.
In short
A unique code identifies the certificate. A public page confirms it by querying the real record. A QR connects the document to that page in a single gesture. And your own domain makes that whole chain speak for your institution instead of a third party’s.