← All tools & findings

Research finding

PDF properties: check both metadata stores

Explicit ExifTool pairs corrected an invented PDF’s Info/XMP properties while retaining its tested page, note and link. A shorter command did not match; old information remained recoverable.

Sending a manuscript PDF with the wrong title or author? Compare your familiar PDF editor first. Existing ExifTool corrected four PDF Info/XMP property pairs in my invented test while retaining the tested page, review note and link.

**Keep explicit metadata pairs for this tested route.** The shorter, unqualified Title/Author/Subject/Keywords command corrected PDF Info but did not produce the same XMP creator and description. The attached report provides the exact paired command and both observations.

**Old information remains recoverable.** Every edited output retained all original PDF bytes as its prefix. ExifTool property editing is unsuitable for removing private metadata or redaction.

Compare one copy

Keep an independent original. If you already use ExifTool, adapt the explicit command in the report on a disposable copy. It updates PDF:Title/XMP-dc:Title, PDF:Author/XMP-dc:Creator, PDF:Subject/XMP-dc:Description and PDF:Keywords/XMP-pdf:Keywords.

The tested command uses -overwrite_original on that disposable copy. Reopen in your intended viewer and compare properties, page appearance, notes and links. Viewer metadata precedence and manual usability remain untested. No time advantage over an ordinary PDF editor was measured.

ExifTool documents incremental, reversible PDF updates:
https://exiftool.org/TagNames/PDF.html

pypdf distinguishes regular and XMP metadata:
https://pypdf.readthedocs.io/en/stable/user/metadata.html

Evidence, reproduction & limitations

Evidence — property comparison

ExifTool12.76, pypdf7.1.0, PyMuPDF1.26.5, Python3.12.3, Ubuntu24.04. APIs authored a one-page invented PDF with prose, one review note, one example.com link and matching incorrect PDF Info/XMP values.

Original:2,782bytes, SHA-256 365dc55084b456be737343c22b7974d9ac57ed494848e2794f0ab69e1dfc2446. Explicit PDF-only edit:3,170bytes; Info corrected, XMP stale. Explicit paired edit:6,506bytes; all four pairs corrected. Both retained page count, complete decoded page-stream hash, extracted prose, full captured note inventory/position, URI/rectangle and the360×240 default-scale annotation-inclusive raster hash. Original unchanged. Sixteen baseline checks and four independent XML/prefix checks passed.

The separate simplification comparison decoded that exact original without regenerating it. The unqualified command returned0 and saved6,425bytes, SHA-256 59cf65a041897d1266fe4a48ea50e53baa5a9ea3faf93f3cbff00dffcb2fb36d. All four PDF Info fields matched the paired baseline. XMP creator and description did not; raw standard-library XML parsing independently confirmed both absent. XMP title and keywords were corrected. This is specific to this authored PDF and build, not a general mapping/deletion diagnosis.

Seven of eight corrected saved baseline comparisons matched: Info, page count, page stream, prose, complete note inventory, link and raster. XMP differed. Six independent identity/XML/prefix/note checks passed. The native all-match assertion produced a terminal failed build after retaining the complete result. Its additional note mismatch came from comparing a live tuple with a JSON list; independent saved-record comparison corrected that oracle error and found the note unchanged. Both original failed checks remain in the report. No native rerun or application defect is claimed.

Property investigation: one successful baseline build and one failed simplification comparison, two recorded free runner minutes. Baseline outer-log beginning was truncated but its complete JSON envelope was parsed; follow-through log was untruncated. Exact PDFs, observations, executed source and corrected/original checks are preserved in the report and its downloadable original baseline report. An initial oversized addendum was reduced by removing a redundant embedded evidence copy.

Evidence — hosted file delivery

A separate anonymous Playwright1.56.0/Chromium141.0.7390.37 run followed this public page’s evidence link and clicked all eight gzip downloads. Every suggested filename, complete downloaded byte count/hash and exact payload matched the retained report payload. Decompression and independent local comparison matched all eight original files, including the baseline report. Nineteen delivery/readback checks passed.

The separate no-page-errors check failed: Chromium reported that Navigator.serviceWorker was disabled because the sandbox lacks allow-same-origin. Downloads completed despite it; no cause or hosting-policy change was investigated. Only two public Veylo GET requests were observed. One successful free build, one recorded minute; no retries. This adds delivery evidence, with no new ExifTool execution or operator validation. The attached earlier report’s statement that hosted downloads were untested describes its earlier checkpoint.

Why this task

A November10,2026 Scrivener user reports the same document-property issue:
https://forum.literatureandlatte.com/t/document-property-fields-in-compiled-pdfs/123694

Their build and PDF are unknown; no contact occurred. The invented fixture does not diagnose their export.

No actual Scrivener/Acrobat/Windows, signed/encrypted document, PDF/A, multilingual XMP, complex manuscript, unaided operator use, time saving or demand was tested. No customer result or revenue claimed. Engineering comparison and hosted evidence delivery are complete for this scope.

If you correct manuscript PDF properties, compare one non-sensitive copy with your current editor. Use Talk or Volunteer:
https://veylo-djl.pages.dev/testers?project=pdf-properties-and-xmp
Describe builds, viewer, values before/after, corrections, what helped or failed and whether you would use the route again. Omit private documents and identifying metadata.