BASALT · JOURNAL
How to see when a PDF was created, and why the dates disagree
To see when a PDF was created, open it in Preview and choose Tools > Show Inspector. The General Info pane lists a Creation date and a Modification date, and those are the dates the software that made the file wrote into it. They're a record of what that software's clock said, not a certificate of when the document came into being.
A PDF can carry up to three separate sets of dates, and the ones Finder shows are usually not the ones inside the file. Downloading a PDF, or copying it in Terminal, gives the new file its own Finder dates and leaves the stored ones alone, and some apps that save a PDF replace the stored creation date with the moment of the save. If two tools give you two answers, they're probably both right about different things.
The three sets of dates
The first set is stored in the document information dictionary, an object the file's trailer points to. Its keys are /CreationDate and /ModDate, written as text like D:20190314093000+01'00': year, month, day, hour, minute, second, then a time zone offset. This is the pair Preview's Inspector shows as Creation date and Modification date.
The second set is in XMP, the XML packet the catalog points to with /Metadata. It uses xmp:CreateDate and xmp:ModifyDate, written in the ISO format, like 2018-01-01T10:00:00Z. Many files have both sets, and nothing forces them to agree. What XMP metadata is explains the packet.
The third set isn't in the PDF at all. It's the file system's record of the file on this disk: when it was created here, when it was last modified, when it was added to a folder. Finder's dates, and the date columns in a folder window, come from here. A file stamped 2019 inside can show today's date in Finder, because the file system date records when this copy was written, not when the document was authored.
What Finder and Spotlight show
Finder shows file system dates, and Spotlight's content creation date is one too. On macOS 15, a test PDF with a stored creation date in 2019 showed the day the file was written to disk when read through Spotlight. It ignored the date stored in the PDF.
You can see this in Terminal. The first command prints the file system dates, and the second prints everything Spotlight reads from the file without adding it to the index:
stat -f 'born %SB, modified %Sm' document.pdf
mdimport -t -d2 document.pdfIn the second output, kMDItemContentCreationDate and kMDItemContentModificationDate are file dates. Don't read them as the PDF's own /CreationDate. Spotlight also ignores XMP, so it can't show you the second set either.
A copy made in Terminal gets its own dates. Run cp document.pdf copy.pdf and the copy's stat birth time is the moment you copied, while the bytes inside, and so the stored dates, are identical. That's why the same PDF can show different dates in Finder on two Macs, or after it's been downloaded from a website or an email.
Reading the stored dates exactly
Preview shows the information dictionary dates, formatted for display, and none of its Inspector panes shows the XMP packet. To see the raw values, install qpdf with brew install qpdf. It only reads. Start with the trailer:
qpdf --show-object=trailer document.pdfThe output includes something like /Info 6 0 R /Root 5 0 R. Print the information dictionary and the catalog by their numbers, then the XMP packet the catalog names:
qpdf --show-object=6 document.pdf
qpdf --show-object=5 document.pdf
qpdf --show-object=7 --filtered-stream-data document.pdfThe first shows /CreationDate and /ModDate as written. The last prints the XMP packet, where you can look for xmp:CreateDate, xmp:ModifyDate and sometimes xmp:MetadataDate. Use your own file's object numbers, not these. If a file has no /Info entry, or no /Metadata entry, it simply doesn't carry that set.
A raw search of the file for these keys can miss them: since PDF 1.5, dictionaries can sit inside compressed object streams. qpdf --show-object reads them either way.
Why a re-saved PDF shows a new creation date
On macOS 15, a PDF re-saved through PDFKit, the PDF framework built into macOS, comes back with the time of the save as both its creation date and its modification date. The Producer becomes the system's own string (on a Mac running 15.6, macOS Version 15.6 (Build 24G84) Quartz PDFContext), and the file is rewritten as a single generation. Title, Author, Creator, Subject and Keywords are kept, and so is the XMP packet, byte for byte.
That last detail is why the dates end up disagreeing. A file whose information dictionary said 2019 and whose XMP said 2018 came out with /CreationDate set to the day of the save, while xmp:CreateDate still said 2018. PDFKit, reading the re-saved file, reported the new date. Only the XMP still carried an old one.
So an app that saves through PDFKit can quietly turn an old document into one "created" today. That result comes from PDFKit's own write call. Whether a given app, Preview included, saves the same way isn't something to assume, so check the Creation date and PDF Producer in the Inspector after saving. The Quartz string next to a brand-new creation date is the sign.
Why none of these dates is proof
Every one of these dates is set by software from a clock. The clock can be wrong, the software can set a different value than the real one, and anyone with the right tool can write a different date into a file. The stored dates, the XMP dates and the file system dates can all be changed without leaving a visible trace in the document.
So read a creation date as a hint. A date that matches the story you were told is mildly reassuring, and a date that doesn't match is a reason to ask questions. It's never proof of when something was written. For a file that matters, such as a contract, a statement or an ID, confirm with the person or organization that issued it. How to tell if a PDF has been edited goes through what else the file can and can't show.
If the dates shouldn't travel with the file
Stored dates are part of what a PDF carries off the page, along with author, producer and sometimes an edit history. If you don't want them to go out with a document, the answer is to remove the information dictionary and XMP, not to try to correct a date. Removing metadata from a PDF on a Mac covers the steps, and how to see a PDF's metadata on a Mac shows what each built-in view leaves out.
Frequently asked questions
Can you see when a PDF was created?
Yes, but only what the file says. Open it in Preview and choose Tools > Show Inspector to read the stored Creation date and Modification date. Those come from whatever software wrote the file, so they show what its clock said when it saved, which is a hint and not proof of when the content was written.
How do I find a PDF's creation date on a Mac?
Use Preview's Inspector for the date stored inside the file, and use Finder's Get Info or stat for the date the file landed on this disk. They often differ. If you need the exact raw value, qpdf --show-object on the information dictionary prints /CreationDate as written, in the form D:YYYYMMDDHHmmSS followed by a time zone.
Why does Finder show a different date from the PDF's creation date?
Finder shows file system dates, which record when this copy of the file was created or changed on this disk. Downloading a PDF, or copying it in Terminal, gives the new copy new file dates while the stored dates inside stay the same. On macOS 15, Spotlight's content creation date was a file date in testing, not the PDF's own.
What is PDF creation date metadata?
It's the /CreationDate entry in the document information dictionary, plus xmp:CreateDate in the XMP packet if the file has one. Both are text values the creating software wrote. PDF 2.0 deprecates most of the information dictionary but keeps /CreationDate and /ModDate, so these two dates stay in current files.
Does a PDF's creation date change when I save it?
It can, depending on the software that saves it. On macOS 15, a PDF written back through PDFKit got the save time as both its creation and modification date, while its XMP packet kept the old xmp:CreateDate. Other software behaves differently, so check the Inspector after saving.
Can a PDF's creation date be faked?
Yes. It's just text in the file, so software can write any value, and the file system dates can be set too. A matching date is not a guarantee, and a missing or odd one isn't proof of anything. For a document that matters, verify it with whoever issued it rather than trusting its metadata.
Why does my PDF have no creation date?
Either the software that made it never wrote one, or something removed it. Tools that clean a file by rebuilding it from its pages leave the information dictionary behind, and the dates go with it. A PDF with no /Info entry in its trailer has no information dictionary dates, though it may still carry XMP dates, and Finder still shows file system dates.
Doing it in Basalt
Basalt won't read a date for you. Its Inspect tool reports which document properties are filled, such as Title, Author and Producer, and whether an XMP packet is embedded, without quoting what they say, and it doesn't report the stored dates at all. To keep dates from leaving with a document, the Strip metadata step in Run a Procedure rebuilds the file from its pages, so the information dictionary, with its stored dates, and the XMP packet are left behind along with bookmarks and tags. Basalt doesn't edit or set dates. It removes them, and it writes a new file with the original untouched. Documents are opened by an engine with no network entitlement. It's $29 once for up to three Macs, free for 24 hours.
Redaction that proves itself
Basalt destroys the content you mark, then re-opens the file it wrote and proves the content is gone before it saves anything. Your documents never leave your Mac.
