Metadata, versions and file structure / The document information dictionary
PDF title, author and subject metadata
The older metadata mechanism: a dictionary in the trailer holding /Title, /Author, /Subject, /Keywords and the creation and modification dates.
Where this API stands
This API does not produce this standard, and there is no option that would. What follows is what the requirement actually is and where a rendered document stands against it. This API has no title, author, subject or keywords option, and writes no /Info dictionary of its own. There is one place where the word title appears in the API surface and it is not this: the `title` class name inside a `header_html` or `footer_html` fragment is substituted at render time and draws visible text on the page, which is ink rather than metadata. The `<title>` element in your markup is worth setting anyway, because it is what that token reflects and what a downstream metadata pass will most naturally pick up, but on its own it does not reach /Info.
What the standard requires
The requirements as a checker enforces them, rather than as a procurement document paraphrases them. A file satisfies all of these or it satisfies none of them.
- /Info in the trailer, referencing a dictionary whose keys are /Title, /Author, /Subject, /Keywords, /Creator, /Producer, /CreationDate and /ModDate.
- Dates are PDF date strings, meaning D:YYYYMMDDHHmmSSOHH'mm', and a malformed one is a common source of a validator complaint.
- PDF/A-1 requires that every entry present here also appears in XMP with the same value, and PDF 2.0 deprecates the dictionary in favour of XMP entirely.
- /Title is what a reader shows in the window bar when /ViewerPreferences /DisplayDocTitle is true, which is why the two are connected.
- Text strings here can be PDFDocEncoding or UTF-16BE with a byte order mark, and a name with an accent in it written the wrong way is the usual cause of mojibake in a file listing.
Who asks for this
Document management systems, email clients showing an attachment name, and anyone whose file listing shows a hundred documents all titled "Untitled". It is also a PDF/UA checkpoint through the DisplayDocTitle requirement.
What it looks like in a file
The concrete form of the thing being described, so you can recognise it in a document you have been handed rather than only in a specification.
# Set the information dictionary and the matching XMP fields together,
# because PDF/A requires them to agree and a later validator will say so.
exiftool \
-Title="Invoice 2026-0481" \
-Author="Northwind Trading Ltd" \
-Subject="Invoice" \
-XMP-dc:Title="Invoice 2026-0481" \
-XMP-dc:Creator="Northwind Trading Ltd" \
invoice.pdfWhat to do about it
Set the information dictionary after the render, with exiftool or any PDF library, and set the matching XMP fields in the same pass so the two agree. If the documents are archived, do this before the archiving step rather than after, because the whole point of the metadata is that the archive can find the file without opening it.
How to check a file rather than assume
`exiftool file.pdf` prints the dictionary in readable form and will show you a date string that failed to parse. `mutool show file.pdf trailer/Info` gets the raw dictionary. Acrobat's document properties panel shows the merged view, which is fine for a quick look and misleading if you are debugging a mismatch.
The mistake people make here
Leaving /Producer and /Creator to say whatever the toolchain put there. It is harmless until a document set goes to a client or a regulator, at which point every file in the bundle is quietly advertising the internal tooling that made it. Setting them explicitly takes one line in the same pass that sets the title.
Frequently asked
Does this API produce The document information dictionary?
Not produced by this API. This API has no title, author, subject or keywords option, and writes no /Info dictionary of its own. There is one place where the word title appears in the API surface and it is not this: the `title` class name inside a `header_html` or `footer_html` fragment is substituted at render time and draws visible text on the page, which is ink rather than metadata. The `<title>` element in your markup is worth setting anyway, because it is what that token reflects and what a downstream metadata pass will most naturally pick up, but on its own it does not reach /Info.
Can I turn on the pdf_a option and be done?
No. The option writes an XMP packet declaring PDF/A-1b into the document catalogue, and the render response comes back carrying a warning that says in as many words that this is best-effort and that full conformance requires tagged structure and an embedded ICC profile. It is a claim written into the file, not a certificate earned by it, and a validator checks the claim against the bytes. Read the warning array in the response rather than taking the absence of an error as a pass.
Should I convert before rendering or after?
After, always. A conformance converter rewrites colour, embeds profiles, sets boxes and stamps metadata on a finished PDF. Trying to satisfy a conformance target from the source side means guessing at what the converter would have done, and the guesses that go wrong are expensive: flattening transparency you did not need to flatten changes what the page looks like.
Standards this one is confused with
The neighbours that matter are the ones people mistake for this, not the ones that sort next to it.
XMP metadata in a generated PDF
An XML packet in the document catalogue carrying the file's own account of what it is: title, author, dates, and any conformance it claims.
PDF 2.0 and what changed in ISO 32000-2
ISO 32000-2, the first version of PDF published by ISO without an Adobe specification behind it, and the base for PDF/A-4.
PDF/UA-1 compliance for a generated PDF
ISO 14289-1: the standard that says a PDF is usable by assistive technology, which in practice means it carries a complete and correct structure tree.
PDF version numbers and what sets them
The version in the file header and optionally in the catalogue, which says which features a reader must understand to open the file correctly.
Linearized PDF for fast web view
A file laid out so a reader can display page one before the rest has arrived, which is what "fast web view" means in a viewer's properties panel.
Every standard, with what this API does about it
The full list, grouped by what the requirement is for, each marked with how far this API gets.
What this API actually does
One page per option and endpoint that exists, with nothing that does not.
Conformance is decided after a file exists. Render the document, then check it, then convert only what the checker actually flags.