How to Set PDF Title, Author, Subject, and Keywords with wkhtmltopdf

wkhtmltopdf has a documented command-line option for the PDF title: --title. It does not document command-line switches for author, subject, or keywords. To set all four fields, generate the PDF with wkhtmltopdf, then update the remaining metadata with a PDF metadata tool such as ExifTool and verify the saved file.

This distinction matters because a heading or HTML <meta> element in the source page does not prove that the corresponding value was written to the PDF’s metadata. The workflow below sets the title during conversion, writes the other fields afterward, and checks the output.

1. Set the title with wkhtmltopdf

The documented option is --title <text>. If you omit it, wkhtmltopdf uses the title of the first document when available. For predictable output, pass the title explicitly:

wkhtmltopdf --title 'Quarterly report' input.html output.pdf

For example, save this as input.html and run the command above:

<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <title>Quarterly report</title>
</head>
<body>
  <h1>Quarterly financial report</h1>
  <p>Report content goes here.</p>
</body>
</html>

The --title option controls the PDF document title. The HTML title is useful as a fallback when the command-line option is omitted, but do not rely on it if the output must have a specific metadata value. The official [wkhtmltopdf usage reference](https://wkhtmltopdf.org/usage/wkhtmltopdf.txt) documents this option, and the [library settings reference](https://wkhtmltopdf.org/libwkhtmltox/pagesettings.html) exposes the corresponding global setting as documentTitle.

Pass a title safely from a shell script

Quote values that contain spaces or shell-special characters. In Bash, variables should be quoted so they remain one argument:

title='Quarterly report: North America'
input='input.html'
output='output.pdf'
wkhtmltopdf --title "$title" "$input" "$output"

When invoking wkhtmltopdf from another program, pass arguments as an argument array instead of building a shell command string. This avoids accidental shell interpretation and makes spaces in paths safe. The exact API depends on the language or process library you use.

2. Add author, subject, and keywords with ExifTool

wkhtmltopdf’s documented option and settings surfaces expose the title, not native switches for author, subject, or keywords. These are separate PDF metadata fields. A practical approach is to use ExifTool after conversion:

wkhtmltopdf --title 'Quarterly report' input.html output.pdf
exiftool \
  -Title='Quarterly report' \
  -PDF:Author='Jane Doe' \
  -PDF:Subject='Quarterly financial report' \
  -PDF:Keywords='finance, quarterly, 2026' \
  output.pdf

The first command creates the PDF with the title set. The second writes the requested PDF information fields. The -Title assignment makes the intended title explicit in post-processing too. This two-step setup is easy to inspect and rerun, and it keeps the HTML conversion step separate from the metadata update.

Write XMP values when downstream systems need them

Some document workflows inspect XMP metadata in addition to the classic PDF information dictionary. The wkhtmltopdf project’s metadata discussion shows an ExifTool workaround that also writes XMP values such as description, creator, and keywords. If your document-management system, indexer, or viewer expects XMP, include corresponding XMP assignments and check that they appear in the final file.

exiftool \
  -Title='Quarterly report' \
  -PDF:Author='Jane Doe' \
  -PDF:Subject='Quarterly financial report' \
  -PDF:Keywords='finance, quarterly, 2026' \
  -XMP:Title='Quarterly report' \
  -XMP:Creator='Jane Doe' \
  -XMP:Description='Quarterly financial report' \
  -XMP:Keywords='finance, quarterly, 2026' \
  output.pdf

Metadata mappings can depend on the utility version and target PDF. Treat the XMP assignments as a workflow choice to validate, not as a guarantee that every viewer will display fields identically. The project’s [metadata issue](https://github.com/wkhtmltopdf/wkhtmltopdf/issues/2253) discusses the limitation and an ExifTool-based workaround.

3. Make the conversion and metadata update repeatable

A reliable build pipeline should stop if conversion or metadata editing fails, and should make it clear which file is the final artifact. This Bash example writes to a temporary PDF, applies metadata, then renames it to the requested output only after both commands succeed:

#!/usr/bin/env bash
set -euo pipefail

input="${1:-input.html}"
output="${2:-output.pdf}"
temp="${output%.pdf}.tmp.pdf"

title='Quarterly report'
author='Jane Doe'
subject='Quarterly financial report'
keywords='finance, quarterly, 2026'

wkhtmltopdf --title "$title" "$input" "$temp"
exiftool \
  -Title="$title" \
  -PDF:Author="$author" \
  -PDF:Subject="$subject" \
  -PDF:Keywords="$keywords" \
  "$temp"
mv "$temp" "$output"

printf 'Created %s\n' "$output"

For production use, also ensure the temporary path is unique when multiple jobs may process the same output name concurrently. Keep the input, temporary file, and final output on a filesystem where the process has appropriate read and write access. If an interrupted job leaves a temporary file behind, it should not be mistaken for a completed deliverable.

Use the wkhtmltopdf C API

When using the library rather than the command-line executable, set the global documentTitle setting before conversion. The setting corresponds to the title field documented by the library settings reference. The research-backed interface detail is the setting name and scope; consult the headers and examples for the exact calling conventions of the wkhtmltopdf build you are compiling against.

Author, subject, and keywords still need to be written after conversion unless your particular integration adds a separate supported mechanism. Do not assume an HTML metadata tag or an undocumented setting will populate those PDF fields.

4. Verify the metadata that ended up in the PDF

Inspect each field in the output file independently. For example, ExifTool can read metadata back from the PDF:

exiftool -Title -Author -Subject -Keywords output.pdf

If you wrote XMP and need to confirm those values too, inspect the XMP fields separately:

exiftool -XMP:Title -XMP:Creator -XMP:Description -XMP:Keywords output.pdf

Check the actual final artifact after all conversion and post-processing steps. A visible heading in the PDF, a browser tab title, or an HTML <meta name="keywords"> element is not evidence that the PDF information dictionary contains the desired fields. If a downstream system matters, verify with that system or a viewer representative of the deployment.

5. Common errors and fixes

Symptom	Likely cause	Fix
The title is present but author, subject, and keywords are empty.	--title sets the title only; the other fields are not documented wkhtmltopdf switches.	Run a metadata post-processing step and inspect each field afterward.
The title is missing or unexpected.	The command omitted --title, or the source document title differs from the intended PDF title.	Pass an explicit --title value and verify the produced file.
The metadata command reports an error or leaves the PDF unchanged.	The file may not exist, may not be writable, or the utility may not accept the selected field mapping for this file.	Check the command’s exit status, file permissions, and utility output; try the classic PDF fields first, then validate XMP separately.
A viewer shows different values than the metadata reader.	The viewer may be displaying XMP, the classic PDF information dictionary, or cached document properties.	Inspect both metadata families and reopen or reload the final file in the target viewer.
The PDF looks correct but has blank metadata.	Rendered page content and document metadata are separate.	Read the PDF metadata directly; do not infer it from page text or HTML tags.
The workflow behaves differently on another machine.	wkhtmltopdf distributions can use different patched-Qt builds.	Record the installed build in deployment diagnostics and verify outputs on the actual packaged version. The available sources do not establish a universal version recommendation.

6. Performance, reliability, and cost considerations

The workflow has two sequential operations: HTML-to-PDF conversion, then metadata editing. The added post-processing step is necessary for fields not exposed in the documented wkhtmltopdf interface. For batch jobs, report failures from both commands separately so a metadata failure does not silently produce a PDF that appears complete but lacks fields.

Build consistency matters because different wkhtmltopdf distributions may use different patched-Qt builds. Pin and record the executable and metadata utility available in the environment, then verify representative outputs after changing packages. There is no universal build recommendation established by the sources used here.

Cost depends on how you run the software and the infrastructure around it; the research sources provide no benchmark or pricing data for wkhtmltopdf or ExifTool. Measure conversion time and resource use with your own HTML, fonts, images, and page lengths if throughput matters. Large or externally dependent pages can affect conversion behavior, so the metadata step should only run after conversion has created a valid output.

7. Or skip the browser setup

If your task is to capture a web page as a PDF rather than render a local HTML document with wkhtmltopdf, ScreenshotNeo is a website screenshot API and MCP server for developers. It can return a screenshot or PDF from one GET request. See the API documentation for its parameters and options.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o page.pdf

For a PDF response, use the documented PDF format parameter from the API docs for your request. ScreenshotNeo’s clean-capture steps can accept cookie or consent banners and remove more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies page verdict and billing status in headers. Its MCP server includes take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

The free plan includes 1,000 shots each month without a card. Paid plans start at $5 for 3,000 shots; every feature is on every plan. If that fits your workflow, sign up free for 1,000 screenshots a month with no card.

8. FAQ

Does wkhtmltopdf support an author command-line option?

The documented usage reference does not list one. Use metadata post-processing and verify the PDF field.

Will HTML keywords be copied into the PDF?

Do not assume so. Verify the PDF metadata directly and write the required field after conversion.

Should I set classic PDF fields, XMP, or both?

Use the metadata format expected by the systems that consume the file. If that is uncertain, write and inspect both, then check the target viewer or repository.

Can I trust the PDF title shown in a viewer?

It is a useful check, but for automation inspect the metadata fields in the final file and validate the downstream consumer’s behavior.

Sources

• wkhtmltopdf usage reference: documents --title.
• wkhtmltopdf library settings reference: documents documentTitle.
• wkhtmltopdf metadata issue: discusses metadata limitations and an ExifTool workaround.