Reading a file rather than trusting its name
A file called invoice.pdf is a claim, not a fact. The extension says what somebody named it; the bytes say what it is. Those come apart often enough to be worth checking — a renamed zip, a truncated download, a file that arrived through three systems and lost something on the way.
Every PDF opens with a signature: the characters %PDF- followed by a version number, in the first few bytes. That marker is what a reader looks for, and its absence is the difference between a document that is damaged and a document that was never a PDF at all. Those two problems have completely different fixes, which is why establishing which one you have comes first.
What the version number means
The version in the header records which specification the producer wrote to, and it is a rough date stamp rather than a quality signal. 1.4 is early 2000s, 1.7 is the version standardised as ISO 32000-1 and by far the most common, and 2.0 is the current one and still uncommon in the wild.
It matters in exactly one situation: something refusing to open your file. Older readers, embedded viewers, and submission portals with validation rules sometimes require a specific version or below, and a file written to a newer one is rejected without explanation. Knowing what you have turns "it does not work" into a specific problem.
Encryption changes what is possible
A PDF can be encrypted in two ways that people constantly conflate. An open password means the file cannot be read at all without it. Permissions mean it opens freely but declares that printing, copying or editing are not allowed.
The second is worth understanding clearly: permissions are a request. They are honoured by readers that choose to honour them and ignored by ones that do not, so a document marked no-copying is not protected in any meaningful sense. It is labelled.
Either way, an encrypted file limits what any tool can tell you about it — metadata may be incomplete and text extraction may be impossible — so knowing it is encrypted explains failures that would otherwise look like bugs.
The metadata is where documents give themselves away
The [msm_tool slug="pdf-inspector"] reports the information dictionary alongside the structural facts: title, author, subject, creator, producer, and the creation and modification dates.
Almost none of it is typed by a person. The author comes from software licence details, which is how documents end up credited to someone who left the organisation years ago. The producer names the library or application that wrote the file, and it is the most informative field of the lot — it tells you a scan came from a particular device, or that a document claimed to be an original export was actually rewritten by an editor afterwards.
The dates are worth reading with the same scepticism. They record when the file was written, which is not necessarily when the work was done, and a modification date later than a document's stated version is a reasonable thing to ask about.
Linearised, and why it exists
A linearised PDF — "fast web view" — is arranged so the first page can render before the rest has downloaded. It matters for large documents served over a slow connection and is irrelevant for anything opened from disk.
Treat it as a fact about how the file was produced rather than a quality to chase. Most documents are not linearised and are none the worse for it.
Page counts on compressed files
One honest limitation worth knowing. Modern PDFs frequently pack their internal structure into compressed object streams, and a count read by scanning the raw bytes can be approximate on those files rather than exact.
Where the number has to be right — a print run, a page limit, a per-page quote — confirm it in a reader, or use a tool that parses the document rather than scanning it. An approximate count is a useful signal and a poor basis for a purchase order.
What inspection is good for
Three situations, mostly. Something will not open: the header tells you whether it is a PDF, and the encryption flag tells you whether you need a password. Something was rejected by a portal or a printer: the version, the page count and the size are the fields those rules test against. Something arrived from outside and you want to know where it came from before forwarding it: the producer string and the dates answer that faster than anything else.
All of it is read from the file in your own browser, which matters for the third case in particular. The documents worth inspecting are frequently the ones you would least want to upload to a stranger's server to find out about.