How to verify a certificate at the laboratory
Which laboratories publish a searchable index, which issue per-record codes, how a vendor’s copy is compared against the laboratory’s, and what a match does not prove.
Topic: Independent verification
Audience: Readers checking a certificate they hold
Reading time: 6–8 minutes
On this page
- 1.Why the laboratory’s copy is the one that matters
- 2.Three routes, and only one of them is open
- 3.The check Prof. Peptide runs, and what it returned
- 4.🔒 A search-code prefix is a shared namespace, not a vendor key
- 5.What a match proves, and what it does not
- 6.The client field settles the spelling
- 7.Where to go next
Why the laboratory’s copy is the one that matters
A certificate published by a vendor is a document the vendor controls. A certificate resolved on the testing laboratory’s own domain is a record the vendor does not control. Where both exist and agree, the document has been confirmed by a party with no stake in the sale.
This is the strongest check available to a reader without a laboratory of their own, and it is also the rarest, because it depends entirely on what the issuing laboratory chooses to publish. Most do not publish anything a reader can query. That is a fact about the laboratory rather than about the vendor whose certificate it issued, and it is why an unverifiable certificate is not the same as a doubtful one.
Three routes, and only one of them is open
Prof. Peptide measured the verification routes offered by the laboratories named across its vendor registry. They fall into three groups, and the difference between them decides how much work confirming a single certificate takes.
- A public, lab-wide index. A searchable list of every certificate the laboratory has issued, each resolving to a PDF on the laboratory’s own domain. Among the laboratories Prof. Peptide cites, Freedom Diagnostics is the only one that publishes one, and it covers tens of thousands of search codes. Anyone holding a search code can resolve it without the vendor’s involvement.
- A per-record verifier. A lookup page that confirms one certificate at a time and requires an access code printed on that certificate. Kovera Labs runs one; there is no queryable list behind it. A reader holding a certificate can confirm it; a reader without one can learn nothing.
- A login portal, or nothing at all. Some laboratories serve certificates by code without publishing an index; at least one runs an account-gated portal. Neither offers a route that starts at the laboratory.
The practical consequence: the cheap check — looking a vendor up at its laboratory — works for one laboratory. For every other, a certificate has to come from the vendor’s own COA page first, and confirmation is a per-vendor visit rather than a lab-wide sweep. That asymmetry shapes what any certificate-verification claim can honestly cover.
The check Prof. Peptide runs, and what it returned
Where a certificate prints a code that resolves on the laboratory’s domain, the vendor’s copy and the laboratory’s copy can be compared directly. It is a short check and it is repeatable by anyone holding the certificate.
The method has three parts. The certificate is taken from the vendor’s own COA page. The search or access code printed on it is resolved on the laboratory’s domain, producing the laboratory’s copy of the same record. The two files are then compared by checksum rather than by eye — a visual comparison of two PDFs of the same certificate will always look like a match.
What it has returned. On one vendor, five incretin certificates were checked against the laboratory’s own domain: four resolved byte-identical to the vendor’s copies, and the fifth matched in content while differing as a file. On two other vendors the same check was run end-to-end on individual certificates and returned byte-identical results. Those outcomes are recorded per vendor rather than generalised — a clean result covers the certificates that were checked and no others.
A content match is not a failure. The same certificate re-exported, re-compressed, or regenerated at a different time produces a different file with identical figures. A byte-identical result is the stronger outcome; a content match is still a confirmation that the laboratory holds the record. Neither is the case worth worrying about — that is a code which does not resolve at all, or one that resolves to a different compound, a different lot, or a different client.
🔒 A search-code prefix is a shared namespace, not a vendor key
The most tempting error on a public index is also the one that produces confident, wrong numbers: treating the leading characters of a search code as a vendor identifier and counting how many codes carry it.
Measured across every vendor in Prof. Peptide’s registry backed by the one laboratory with a public index, every four-character prefix held certificates from more than one company. A prefix matching one vendor’s name also returned two other companies with similar names. Another returned a second, unrelated company. One four-character prefix covered thousands of codes belonging to several businesses at once.
An exact per-vendor certificate count therefore requires reading the client field of every code under a prefix, one at a time. Prof. Peptide published two such counts before measuring this and withdrew both. No certificate count appears anywhere on this site unless the vendor or the laboratory publishes it as a figure about itself — a paginator reading “Showing 1–10 of 91” is search-result state, not a vendor’s statement, and seven numbers that looked exactly like vendor figures were refused on that basis.
What a match proves, and what it does not
A confirmed certificate is a narrow result. Reading it as broader than it is undoes the value of having checked.
- It proves the laboratory issued that record. The document is not fabricated and the relationship between vendor and laboratory is real for that certificate.
- It does not cover the catalog. One confirmed certificate covers one lot of one compound. Extending it to everything the vendor sells is the same error as reading a specimen page as proof of testing.
- It does not date the vial. A certificate confirms a lot tested on a date. Whether a vial shipped today belongs to that lot is a separate question, answerable only where the lot is printed on the vial.
- It says nothing about accreditation. Whether a laboratory holds ISO/IEC 17025 is a separate fact, stated separately or not at all. Accreditation stated as pending is not accreditation held.
- A failure to resolve is often about access. Roughly one in twelve certificates sampled from the public index were scans with no text layer, unreadable to automated tools and perfectly legible to a person. A page returning an error to an automated request frequently opens in a browser. Prof. Peptide recorded three vendors as blocked on a single failed request and found all three readable on retry.
The client field settles the spelling
A small practical point that resolves a recurring ambiguity: when a laboratory, a vendor and a marketing page disagree about how a company is written, the certificate wins.
The client field on a certificate is how the laboratory recorded the company that commissioned the test. It is more reliable than the laboratory’s own website, more reliable than the vendor’s prose, and considerably more reliable than any third party’s summary — this site’s included. Where Prof. Peptide’s registry names a laboratory as verified for a vendor, the record behind it is a certificate whose client field was read directly.
Where to go next
Verification confirms a document. Reading it is the step before.
- How to read a certificate of analysis — the fields that tie a document to a vial, and the difference between a specimen and a certificate.
- Testing laboratories — the laboratories named across the vendor registry.
- Vendor COA and testing-transparency index — what each vendor publishes, and which laboratory is named on its certificates.
We may earn commissions from peptide vendor affiliate links.
