Direct answer: upload an authorized copy to PDFCheck and read Created in Document Timeline. Treat it as the date recorded inside the PDF—not proof of when the content was written, first saved, signed, or submitted. Before relying on it, compare the modification date, software fields, XMP metadata, the date printed on the page, and an independent record such as an email, portal receipt, source-file history, or trusted timestamp.
First-screen reliability check
| What you find | What it means | Next action |
|---|---|---|
| One embedded date, no conflict | A useful lead, still editable | Record the value and timezone; corroborate it if the decision matters |
| Creation and modification dates differ | Normal after a later save, export, or metadata change | Inspect software, signatures, and the source history |
| PDF date differs from Finder or File Explorer | You are comparing embedded metadata with a file-system timestamp | Identify which date answers your question; neither automatically overrides the other |
| Date is missing, impossible, or has no timezone | The timeline is incomplete or ambiguous | Do not infer a precise instant; recover evidence from the source or receiving system |
| A trusted signature timestamp validates | Stronger evidence that the signed data existed by that time | Keep the original bytes and validation record; do not equate it with the editable creation field |
The safest wording is “this PDF records a creation date of …” rather than “this document was created on …”. That small distinction prevents an editable field from becoming a forensic conclusion.
Five different “PDF dates” people confuse
1. PDF Info creation date
/CreationDate is a conventional field in the document information dictionary. The creating or editing software writes it, and software can later change or remove it.
2. XMP creation date
xmp:CreateDate can carry a similar value in XML metadata. It may agree with the Info field, disagree with it, or exist alone.
3. File-system “Created” date
macOS, Windows, a cloud drive, or a server records when that file entry appeared in that location. Copying, downloading, restoring, or syncing can change it without changing the PDF.
4. Date visible on the page
A letterhead, invoice date, scan stamp, or typed contract date is page content. It can predate or postdate the PDF file and is not automatically synchronized with metadata.
5. Signature or trusted timestamp
A digital signature can include signing time, while a trusted timestamp uses a timestamp authority. When cryptographically validated, it can provide stronger evidence that particular data existed by a time—but it still does not prove when the document's words were first drafted.
Adobe documents both the legacy document information dictionary and XMP metadata in its PDF metadata overview. The PDF Association's metadata guide also separates PDF metadata from file-system metadata. That is why two values labeled “Created” can both be accurate descriptions of different events.
How to check the recorded creation date with PDFCheck
- Preserve the original. Save a separate working copy and record where the original came from. Re-saving can change metadata or signatures.
- Open PDFCheck. Upload only a file you are authorized to use and that your privacy or retention rules allow.
- Confirm the report and read Document Timeline. Record the Created and Last Modified values exactly, including the displayed timezone or absence of one.
- Check the surrounding metadata. Compare Creator, Producer, PDF version, title, author, XMP fields, and document-health notes. A coherent set is more useful than one isolated date.
- Inspect signature context when relevant. Use the PDF Signature Checker before editing or re-exporting, but remember that structural detection alone is not identity validation.
- Corroborate proportionately. For a casual sort, the embedded date may be enough. For a dispute, audit, payment, or legal decision, obtain independent records and specialist validation.
PDFCheck capability boundary: PDFCheck reports parsed metadata dates, related software fields, and heuristic document-health context. Its Date Reliability result is an internal consistency check—not a certificate, trusted timestamp, cryptographic validation, forensic conclusion, or legal opinion. PDFCheck cannot prove who set a date, when the content was first drafted, whether an older value was removed, or whether a court, regulator, bank, or recipient will accept the date.
Why the recorded date may be wrong or misleading
- The device clock was wrong. A correctly formatted field can still record a false local time.
- The timezone is missing or malformed. A wall-clock time without a reliable offset cannot identify one precise global instant.
- The PDF was exported from an older source. A 2024 document can legitimately become a PDF in 2026.
- A template carried old metadata. Duplicating a prior file may preserve its title, author, or date.
- A scan created a new digital file. The PDF date may describe scanning, not the age of the paper.
- Software rewrote or removed metadata. Adobe's metadata documentation explicitly provides ways to edit, replace, append, and delete metadata.
- Info and XMP were updated differently. A conversion may change one metadata system while leaving the other untouched.
- The file was copied or downloaded. This often changes the file-system timestamp while embedded PDF fields remain the same.
An evidence ladder for deciding whether to trust the date
| Evidence | What it can support | Main limitation |
|---|---|---|
| One embedded creation field | The value present when inspected | Editable and may reflect export rather than authorship |
| Consistent Info, XMP, software, and modification fields | A more coherent internal timeline | All remain under the file creator/editor's control |
| Original source history or content system log | When a version was saved or exported in that system | Depends on access controls, retention, and log integrity |
| Independent email, portal receipt, or archive record | The file or a matching copy existed by a recorded event | You must match the record to the exact bytes or version |
| Validated digital signature with trusted timestamp | The signed data existed before the authority's timestamp | Does not prove when the underlying content was first drafted |
The IETF's RFC 3161 Time-Stamp Protocol describes evidence issued by a trusted third party that a datum existed before a particular time. A plain /CreationDate string has no equivalent guarantee.
Failure states and recovery actions
| Failure state | Do not conclude | Recovery |
|---|---|---|
| No creation date | That the PDF is fraudulent or ancient | Check XMP, source history, sender records, and the receiving system |
| Creation is later than modification | That tampering is proven | Check timezone parsing, clock settings, Info/XMP mismatch, and export software |
| Finder date is today; PDF date is years old | That one value is necessarily fake | Confirm whether the file was downloaded, copied, restored, or unzipped today |
| Date on the page differs from metadata | That the page or metadata alone proves the timeline | Obtain the source document, version history, and submission record |
| Info and XMP disagree | Which one is original | Preserve both values, identify the writing software, and seek independent evidence |
| PDFCheck cannot open the file | That the absence of a report says anything about the date | Use an authorized offline tool, obtain an uncorrupted original, or screen the file with the PDF Validator |
Three realistic examples
A downloaded invoice says it was created two years ago
Finder says the file was created today because the download created a new local file entry. The PDF's embedded creation date says 2024 because that is what its producer recorded. Use the supplier portal, email receipt, invoice number, and the exact downloaded bytes to establish the business timeline.
A scanned contract has a recent PDF date
The paper may have been signed years before it was scanned. The PDF date can reasonably describe the scan/export event, not the contract's execution. Check the visible signatures, custody record, scanner workflow, and any original paper or source record.
A disputed PDF shows matching creation and modification dates
Matching values remove one inconsistency but do not prove the values are true. Preserve the file, calculate a hash through an approved process, inspect any signatures with the Signature Checker, and request the original email, portal log, or version history. For high-stakes matters, use a qualified forensic professional.
Offline check when the file cannot be uploaded
On a trusted machine with Poppler installed, run pdfinfo document.pdf to view common document properties. To inspect XMP, run pdfinfo -meta document.pdf. These commands report what the parser finds; they do not authenticate the values. Keep sensitive output out of tickets and chat.
If the values are stale and you own the document, follow the safe metadata-editing workflow on a copy. Editing the date makes the metadata more accurate for future use, but it cannot reconstruct a historical timestamp or preserve an existing signature.
Final checklist
- □ The original file remains unchanged and its source is recorded.
- □ The embedded creation and modification dates were copied exactly, including timezone information.
- □ Info, XMP, file-system, visible-page, and signature dates were not conflated.
- □ Creator, Producer, PDF version, signatures, and document-health context were reviewed.
- □ Missing, impossible, or conflicting values were recorded rather than “corrected” in the original.
- □ The strength of corroboration matches the consequence of the decision.
- □ Any report says “the PDF records” unless stronger independent evidence supports more.
A PDF creation date is a useful clue. The reliable workflow is to preserve the file, identify which clock you are reading, compare the internal fields, and corroborate the result before turning that clue into a claim.