Scanned PDF Metadata: What the File Says About Itself

Scanned PDF metadata is the short record a scan keeps about itself: a creation date, a modification date, the software or device that wrote the file, and sometimes a title, author, subject and keywords. It describes when and how the PDF was made. It says nothing reliable about the paper document the pages show.

That gap between the file and the paper is the whole subject. A lawyer looking at the properties of a scan is reading facts about a scanning event, recorded by a machine with a clock that may be wrong, in fields that any later program may rewrite.

What metadata does a scanned PDF carry?

A scanned PDF can carry up to nine standard fields of metadata: title, author, subject, keywords, creator, producer, creation date, modification date and a print-production flag called Trapped. Every one of them is optional. A scan may fill in two or three and leave the others out entirely.

The fields are defined in Table 317 of the PDF standard. The wording in this table comes from the published copy of ISO 32000-1, the PDF 1.7 standard, clause 14.3.3.

Notice how the creator and producer definitions assume a document that was "converted to PDF from another format", such as a word-processing file. A sheet of paper has no creating application. Scanning software has to decide for itself what to write in those two fields, which is why they vary from one device to the next.

The standard also tells software what to do with a field it cannot fill: "Any entry whose value is not known should be omitted from the dictionary rather than included with an empty string as its value." An absent field on a scan is therefore normal, and proves nothing.

A file made in a word processor has more to say about itself, including fonts, links, bookmarks and form fields. The comparison of native and scanned files lists what else a native PDF carries that a scan lacks.

Why is the creation date of a scanned PDF not the date of the document?

The creation date of a scanned PDF records the moment the scanning software wrote the file. The paper may have been signed that morning or forty years earlier. The date in the file's properties and the date printed on the page are two separate facts, and only the second is about the document.

Take a fictional file. A deed of trust for a Marlowe Street property is dated June 3, 1994, on its face. Opposing counsel's office scans it on a Thursday in 2026 and emails it. The properties show a creation date in 2026. Nothing in the file knows about 1994 except the picture of the page.

Four separate dates are in play whenever you look at a scan, and they are easy to mix up.

The last row trips people up. The "Created" and "Modified" times your computer shows in a folder listing describe the copy sitting on your disk. Saving an email attachment gives the file a fresh creation time on your machine, even though nothing inside the PDF changed. The dates inside the PDF travel with the file. The dates in the folder listing do not.

How a PDF writes a date

The standard sets the format in clause 7.9.4: a text string beginning D:, followed by year, month, day, hour, minute and second, and then the relationship of local time to Universal Time. A value looks like this:

D:20260917143205-05'00'

Read left to right, that is September 17, 2026, at 14:32:05, on a clock five hours behind Universal Time. A PDF reader turns the string into a friendlier display, and may convert it to your own time zone as it does so. Two people in different offices can therefore see different clock times for the same file and both be reading it correctly.

Only the year is required. The standard says the remaining parts "may be present", and that when no time zone information is given the relationship to Universal Time "shall be considered to be GMT". A copier that writes local time with no offset may therefore be displayed by a reader as though it were GMT.

The clock behind the date

A scanner knows the time only because someone set its clock, or because it asks a network time server. A device that was never set up, lost power, or sits in the wrong time zone setting writes a wrong date with complete confidence. A creation date of January 1 in a year long past can be the mark of a clock that was never set.

If the scan date matters in your matter, treat the properties as a starting point and look for something independent: the email that carried the file, a scan log on the device, or a statement from the person who stood at the machine.

Properties never record the jurisdiction or the venue printed on a pleading. Where the file has text, search for each party and for any statute cited on venue. The creation time is a fact about the scanning session. The date on the pleading is another fact, and you get it by reading the page.

Title, author and producer fields a scanner or copier fills in

A scanner or copier fills the title, author and producer fields with whatever its software was built or configured to write: a device name, a software name, a job number, a login name, or nothing. No rule requires any particular value, so the only way to know what your equipment writes is to look.

This is a five-minute exercise, and it is worth doing once for every device in the office.

1. Scan one blank sheet on the device, using the settings staff normally use.
2. Open the file in a PDF reader and choose File, then Properties.
3. Copy every field in the properties window into a note, including the blank ones.
4. Repeat while logged in to the device as a named user, if the device supports logins.
5. Repeat using scan-to-email and scan-to-folder, if both are in use. They can run through different software.

A fictional result, for the copier at Okafor Reyes LLP:

Three things in that small table deserve a second look before a scan like it leaves the firm.

• The author field holds a login name. Every scan a logged-in user sends out announces who operated the copier. That may be harmless, or it may be more than you meant to tell the other side.
• The creator field holds a device name. Names chosen by an IT department can reveal an office location, a floor or a client-specific machine.
• The title is a timestamp. It repeats the scan time in a place people forget to check.

Whether any of this should be removed before a file is served or produced is a separate question, and one with rules attached in some settings. The post on hidden text covers metadata as one of the kinds of other hidden content a PDF can carry and how to look for it before a file goes out. Do not strip metadata from documents you are required to preserve or produce as kept without checking what your obligations are.

What does running OCR add to or change in a PDF's metadata?

Running OCR on a scanned PDF means a program opens the file, adds a text layer and saves a new version. That save is the point at which metadata can change. The modification date may move forward, and the producer may be replaced by the name of the program that did the saving.

Nothing in the PDF standard requires recognition software to record that recognition happened. There is no "OCR applied" field. What you see afterwards depends entirely on the program, so the reliable approach is a before-and-after comparison on one file:

1. Take a scan straight from the copier and note its properties.
2. Run it through your OCR tool and save or export the searchable PDF.
3. Note the properties of the result.
4. Compare the two lists field by field.

The possible outcomes for each field, and what each tells you:

The second creation-date row matters most. If a tool builds a fresh PDF, the searchable copy can carry a creation date that is the day you ran recognition. Someone who later sees only that copy could take the recognition date for the scan date. Keep the file as it arrived alongside any converted version, so the earlier dates are still on record somewhere.

Schema Law's searchable PDF export is described on the site as your original file with a hidden text layer. The site does not say what the export does to each property field, so run the four-step comparison on one of your own files before relying on any date in an exported copy. The export options are listed under formats.

A producer field that names recognition software is one of several clues that a file already has a text layer. The post on OCR files sets out the full list of signs that a file has already been through OCR.

Document information and XMP: the two places a PDF stores metadata

A PDF can store metadata in two places. The document information dictionary is a short list of fields. The metadata stream is a block of XML in a format called XMP. The same title or date can appear in both, and the two copies can disagree.

The PDF 1.7 standard describes both in clause 14.3 and states their relationship in a note: "Document information dictionaries is the original way that metadata was included in a PDF file. Metadata streams were introduced in PDF 1.4 and is now the preferred method to include metadata."

The document information dictionary

The document information dictionary is the home of the nine fields in Table 317. It is the older of the two stores. The standard says the optional Info entry in the file's trailer holds it, and a PDF reader's properties window may draw on it.

The XMP metadata stream

XMP stands for Extensible Metadata Platform. Adobe's XMP specification, part 1, defines its own set of properties, with names that differ slightly from the dictionary's. Among them:

The specification adds a caution about the first of these that applies to every date discussed in this post. For a digital file, it says, the creation date "need not match a file-system creation time", and later "file transfer, copying, and so on, can make the file-system time arbitrarily different."

XMP can also hold far more than four properties. Software can add its own, which is how a file may record a history of the programs that touched it. Whether a given scan has any of that depends on the software that wrote it.

When the two disagree

A program that understands only the older dictionary can update a date there and leave the XMP copy untouched. The standard anticipates this. If the XMP date stamp is equal to or later than the modification date in the dictionary, "the metadata stream shall be taken as authoritative." If the dictionary's modification date is later, the document "has likely been saved by a writer that is not aware of metadata streams", and the dictionary's values override.

For a reader of scans, the practical point is simpler than the rule. The properties window in your PDF reader may be showing you one store, the other, or a blend. If a date matters, look at both. Look in your PDF program for an additional or advanced metadata view that shows the XMP as written. Not every program has one. A mismatch between the two stores tells you that at least two different programs have saved the file.

The archival form of PDF has its own requirements about metadata. The post on what PDF/A is covers that standard and how a file is validated against it.

Reading the properties of a scan someone else sent you

The properties of a scan someone else sent you show how the file describes itself at the moment it reached you. They support modest inferences about how the PDF was made and saved. They cannot tell you who wrote the paper, when it was signed, or whether the pages are complete and unaltered.

A routine for a file that matters

1. Save the file exactly as received, and work on a copy. Opening a PDF does not alter it, but saving from some programs does.
2. Record the properties before doing anything else. A screenshot of the properties window, kept with the matter, is enough.
3. Check both metadata stores if your software shows them.
4. Compare with the outside evidence: the email's sent time, the cover letter, any transmittal log.
5. Read the page images for their own evidence: fax header lines, received stamps, Bates numbers and page counts say more about the paper's history than the properties do.
6. Ask. If a date or a source matters, a question to the sender about how and when the scan was made costs little.

What metadata is not

Metadata fields are ordinary, editable text. Any PDF editor can change a title or an author, and a program can rewrite a date. So a clean set of properties is not proof of an untouched file, and an odd set is not proof of tampering. Either is a reason to ask a question, not an answer.

How much weight a court gives to file properties, and what is needed to authenticate a scanned document, depends on the rules of evidence and procedure where you practise. This post describes what the fields are. It does not say what they prove.

Your own outgoing files deserve the same reading. Before a scan leaves the office, open its properties and decide whether the login name, device name and timestamps in it are things you are content to send. For files you upload to Schema Law, the site's security commitments say that documents stay inside your own account and that you can delete any document, with the original file and everything parsed from it, whenever you choose.