Public reader: a check the file's holder can run
A public reader is a checking route the holder of a file can run themselves. Distance from the file is what decides a route's value: a check through a support queue is a different instrument from a tool. As of 2026-09-22.
| The term | Public reader |
|---|---|
| What it names | A checking route usable without the vendor's cooperation |
| What it is not | A promise that the check will find something |
| Where the register uses it | Three detection facts, at three distances |
Inclusion rule. Words this site uses in a narrow sense, where the ordinary sense would lead a reader to misread a cell. No vendor statement appears on this page. Order. Fixed order: what the word names, what it excludes, then where it is used here.
1Three distances, in one register
Closest: a tool the holder runs, such as publicly available credential inspection or an assistant that examines an upload. Middle: a portal described as in testing with a limited group, which is public in principle and not yet available in practice. Furthest: detection described as internal to the vendor.
All three are published routes and the register records them as such, with the wording each vendor used. What differs is whether the person holding a file can get an answer today, which is the only question a publisher is actually asking.
2Why the furthest one is still worth recording
Because it tells a reader that the signal exists and who can read it, which is different from a vendor saying nothing. A file may carry a mark that only the originating company can interrogate, and knowing that is useful even though it cannot be used.
It also predicts behaviour in a dispute. A vendor with internal detection can be asked, under whatever process it chooses to run, on its own timetable and with its own interest in the answer. That is a route with characteristics rather than no route at all.
3What a public reader does not make true
That the check will succeed. An attached record can be lost in an ordinary re-encode, and one vendor publishes exactly that caveat, so a public route can return nothing on a file that genuinely came from the product.
And that a negative result means anything. A publisher reasoning from a failed check to a conclusion about a file is reasoning in the direction no route in this register supports, which is worth knowing before a route is treated as a test.
Nothing on this page is a vendor statement; the values it helps read are on the support table, with the page and the date each one was read from. See also the user toggle column, source documents. Nearby terms: internal detection, metered access, two-route product.