2 PDF Metadata Cleanup Methods for .NET - Sanitize vs Author Removal Leave feedback

Note

Full working example available on GitHub: https://github.com/groupdocs-metadata/strip-pdf-metadata-dotnet

PDF metadata cleanup is a GroupDocs.Metadata workflow for .NET that strips Author-style Info dictionary and XMP fields from PDFs before they leave a service. Author, Creator, Producer, Keywords, and XMP packets often survive “Save As” and browser downloads. Teams that share contracts need a server-side cleanup step that can prove Author-style identity is gone.

I reached for this pattern after a partner still saw Author = Alice Example on a draft we thought a browser cleaner had already scrubbed.

Two cleanup intensities show up in real pipelines: erase every detected package before a file leaves a trust boundary, or strip only person-tagged fields when Title and Subject must stay. GroupDocs.Metadata for .NET supports both on the same Metadata object.

This guide compares 2 primary cleanup methods for PDF documents using GroupDocs.Metadata for .NET, plus inspect and verify steps. Each method is evaluated on complexity, suitability, and maintenance.

You will see when to call Sanitize() for a full wipe, when to call RemoveProperties for Author-style fields only, how to baseline with FindProperties, and how to verify Author / Person.Creator after Save.

Prerequisites:

• .NET 8 SDK and NuGet access to GroupDocs.Metadata 26.8.0
• A PDF that still carries Info dictionary and/or XMP identity fields

Note

Complete Source Code: All examples are available in our GitHub repository. Clone, run, and customize for your needs.

Overview: Calls Sanitize() on a loaded PDF to clear recognized metadata packages, including Info dictionary fields and XMP, then saves a new file. Use when no authorship trail should remain.

Open the PDF with Metadata, call Sanitize(), print the removed-property count, and Save to an output path. The call targets detected packages rather than asking you to list every field name by hand. It is the blunt instrument for outbound hygiene.

• вњ… Partner or public download links
• вњ… Cross-tenant document exchange
• вњ… “Leave no Author trail” policy exits

Pros:

• One call covers Info and XMP packages the API detects
• Small code surface; easy to wrap in a service method
• Returns a removal count you can log

Cons:

• Removes descriptive fields you may still need for filing
• After Save, Tool.Software Creator/Producer may be rewritten by the PDF engine
• Evaluation licensing can block unrestricted Save

using var metadata = new Metadata(inputPath);
int removed = metadata.Sanitize();
Console.WriteLine(removed);
metadata.Save(outputPath);

For single-page contract PDFs the pass is dominated by open/save I/O. Log removed so operators can spot empty cleans versus large wipes.

Overview: Uses RemoveProperties with person/creator tags and Author/Creator/Producer name checks so identity is stripped while Title, Subject, and Keywords can remain.

Build a predicate that matches Tags.Person.Creator, Tags.Person.Editor, and common identity property names. RemoveProperties deletes matches only. Save the result, then inspect again to confirm descriptive fields survived.

• вњ… Records systems that index Title/Subject
• вњ… Redacting people from circulating drafts
• вњ… Policies that ban Author but allow keywords

Pros:

• Selective: keeps filing metadata that search depends on
• Predicate is explicit and reviewable in code review
• Same Metadata API as Sanitize

Cons:

• You must maintain the predicate as new identity fields appear
• Creator/Producer name matches can overlap tool fingerprints after Save

using var metadata = new Metadata(inputPath);
int removed = metadata.RemoveProperties(p =>
    p.Tags.Contains(Tags.Person.Creator) ||
    p.Tags.Contains(Tags.Person.Editor) ||
    string.Equals(p.Name, "Author", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Creator", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Producer", StringComparison.OrdinalIgnoreCase));
Console.WriteLine(removed);
metadata.Save(outputPath);

Filtered removal still loads the metadata model once. Cost stays close to Sanitize for small PDFs; the win is semantic, not CPU.

Overview: Read-only listing of Author, Creator, Producer, Title, Subject, and Keywords for a before/after baseline.

• вњ… First step in any cleanup job
• вњ… Debugging “we thought it was clean” tickets

using var metadata = new Metadata(inputPath);
var properties = metadata.FindProperties(p =>
    p.Tags.Contains(Tags.Person.Creator) ||
    p.Tags.Contains(Tags.Tool.Software) ||
    p.Tags.Contains(Tags.Content.Title) ||
    p.Tags.Contains(Tags.Content.Subject) ||
    string.Equals(p.Name, "Author", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Creator", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Producer", StringComparison.OrdinalIgnoreCase) ||
    string.Equals(p.Name, "Keywords", StringComparison.OrdinalIgnoreCase));

foreach (var property in properties)
{
    Console.WriteLine($"{property.Name} = {property.Value}");
}

Overview: Re-opens the cleaned PDF and prints True when Author / Person.Creator / Person.Editor leftovers are absent. Ignore Tool.Software Creator/Producer fingerprints rewritten on Save.

• вњ… CI assertion after cleanup
• вњ… Distinguishing Author removal from engine stamps

using var metadata = new Metadata(inputPath);
var leftovers = metadata.FindProperties(p =>
    p.Tags.Contains(Tags.Person.Creator) ||
    p.Tags.Contains(Tags.Person.Editor) ||
    string.Equals(p.Name, "Author", StringComparison.OrdinalIgnoreCase));

Console.WriteLine(!leftovers.Any());

Challenge: Legal shares a draft PDF that still shows Author = Alice Example and Keywords marked confidential.

Solution: Run inspect, then Sanitize(), then verify Author is gone before uploading to the partner portal.

Result: Removal count is logged (for example 7), and verify prints True for Author-style leftovers.

Challenge: Records still need Title and Subject, but person names must not travel in Author.

Solution: RemovePdfAuthorMetadata with the person/creator predicate, then inspect to confirm Title/Subject/Keywords remain.

Result: Author-style fields drop (for example 3 removals) while descriptive fields stay searchable.

Re-open the cleaned PDF and look only for Author / Person.Creator / Person.Editor. Residual Creator or Producer values tagged as Tool.Software are often PDF-engine fingerprints written on Save, not the original author identity. Treat those stamps as expected noise. Score the cleanup as failed only when Author-style leftovers remain. That distinction keeps CI checks honest and matches what compliance reviewers actually ask after a metadata wipe on GroupDocs.Metadata for .NET.

Sanitize() clears recognized metadata packages detected on the PDF, including Info dictionary fields and XMP when present. Always inspect before and after on your own files.

Yes. Use RemoveProperties with a person/creator-focused predicate like the sample.

GroupDocs.Metadata 26.8.0 on .NET 8.

Pick Sanitize when a PDF exits a trust boundary and nothing identity-related should remain. Pick RemoveProperties when Title and Subject must survive. Wrap both with inspect and Author-focused verify so operators can see before/after evidence.

Next steps: clone strip-pdf-metadata-dotnet, run the console app against Resources/contract-with-metadata.pdf, then wire the same methods into your upload service.

• GroupDocs.Metadata for .NET - remove all metadata
• GroupDocs.Metadata for .NET - remove specific properties
• Blog article: remove PDF metadata (.NET)
• GitHub sample repository
• API reference