PDFCanon vs. Glasswall: Deterministic PDF Normalization vs. CDR

Glasswall and PDFCanon both handle PDFs in security-sensitive contexts. They answer different questions.

Glasswall is primarily a Content Disarm and Reconstruction platform. Its job is to neutralize risky file content before it reaches a user or system.

PDFCanon is a deterministic PDF normalization API. Its job is to turn untrusted PDFs into byte-stable canonical documents with stable SHA-256 hashes and machine-readable audit reports.

If your question is "Is this file safe to open?" Glasswall is built for that world.

If your question is "Is this file safe, stable, auditable, and verifiable?" PDFCanon is built for that world.

The core difference

Dimension	Glasswall	PDFCanon
Primary category	Content Disarm and Reconstruction	Deterministic PDF normalization
Main promise	Neutralize threats in files	Produce canonical PDFs with stable hashes
Best fit	High-security file exchange	SaaS upload pipelines, audit trails, deduplication
Output contract	Safe reconstructed file	Byte-stable canonical file within pinned toolchain
Audit artifact	Security-focused processing evidence	Machine-readable normalization and integrity report
Deterministic hashing	Not the main product promise	Core product promise

What Glasswall is good at

Glasswall is a serious security product. It is strongest when file security is the primary goal and the organization needs a CDR layer for high-risk document flows.

That can make sense for:

• Government and defense workflows
• High-security financial services
• Email attachment sanitization
• File transfer gateways
• Environments where threat neutralization matters more than byte identity

CDR systems generally work by inspecting a file, stripping or rebuilding risky parts, and producing a safer output. That is useful, especially when the alternative is passing raw files through unchecked.

What CDR usually does not promise

CDR is not usually designed around deterministic canonical hashing.

A reconstructed file may be safer, but that does not mean:

• The same input always produces the same bytes.
• The same canonical SHA-256 can be reproduced across toolchain versions.
• Incremental update history is collapsed in a way designed for deduplication.
• Metadata drift is removed as part of an integrity contract.
• Every transformation is represented in a normalization report built for auditors and developers.

This is not a criticism of CDR. It is a different category.

Where PDFCanon fits

PDFCanon is for systems where PDFs become records.

Examples:

• A legal-tech app stores signed contracts.
• A healthcare platform accepts intake forms.
• A fintech app receives statements and invoices.
• An HR platform stores identity documents.
• A contract workflow needs deduplication and stable evidence chains.

In these systems, "safe enough to open" is not the only requirement. The application also needs to prove what was received, what changed, and whether the normalized output is stable over time.

PDFCanon gives each processed document:

• A canonical PDF
• A stable SHA-256 for the normalized bytes
• A content hash when text can be extracted
• A stage-by-stage audit report
• Toolchain version metadata
• Tamper and active-content findings

A practical example

Imagine a customer uploads a contract PDF with:

• 14 incremental updates
• A stale /OpenAction
• Metadata timestamps from multiple tools
• An embedded file attachment
• A visual contract that appears normal in a viewer

A CDR product focuses on making the file safe by removing or reconstructing risky content.

PDFCanon focuses on making the resulting document safe, stable, and explainable:

{
  "canonicalSha256": "c891a0...7f02",
  "stagesRun": [
    "TamperDetection",
    "StructuralRepair",
    "ActiveContentRemoval",
    "MetadataCanonical",
    "FinalRewrite"
  ],
  "removed": {
    "openActions": 1,
    "embeddedFiles": 1,
    "incrementalUpdates": 14
  },
  "toolchain": {
    "qpdfVersion": "pinned"
  }
}

That report is meant to be stored with the document and shown to engineering, security, and compliance teams.

When to choose Glasswall

Choose Glasswall when:

• Your main buying center is security operations.
• You need broad CDR across multiple file types.
• You have high-security document exchange requirements.
• Threat neutralization is more important than byte-stable identity.
• You need enterprise CDR controls and certifications.

When to choose PDFCanon

Choose PDFCanon when:

• Your product accepts user-uploaded PDFs.
• Stable hashes matter for deduplication, signing, archiving, or evidence.
• Auditors ask what happened to each uploaded file.
• You need a JSON report your application can store and query.
• You want a deterministic API contract, not a black-box file sanitizer.

Can you use both?

Yes. In some high-risk environments, a CDR layer and a canonicalization layer can complement each other.

A common pattern:

1. Run broad file security screening.
2. Normalize PDFs into canonical form.
3. Store the canonical PDF and audit report.
4. Use the canonical SHA-256 for deduplication and evidence chains.

The order and policy depend on the system, but the conceptual split is useful: CDR reduces threat risk; canonicalization makes the resulting document stable and auditable.

Bottom line

Glasswall is strong when the central question is file threat neutralization.

PDFCanon is purpose-built when the central question is PDF integrity: stable bytes, stable hashes, and a report that proves what changed.