Knowing what a file is does not tell you whether the file is healthy.

A digital archive may identify an object confidently as PDF, TIFF, JPEG 2000, WAVE or another known format and still discover that the object is truncated, internally inconsistent, malformed, non-conformant to a required profile or dependent on features that the repository cannot preserve safely.

This is where file format validation begins.

Identification asks What is this? Validation asks a stronger question: Does this object obey the structural and semantic rules required by the format or profile we believe it belongs to?

The distinction sounds technical. Operationally, it is the difference between putting a label on a box and checking whether the contents actually satisfy the specification written on that label.

The short answer

File format validation compares a digital object’s structure and properties against formal or implementable rules for its format. A validator may test syntax, required elements, internal relationships, value constraints, profiles and other conformance conditions. In digital preservation, tools such as JHOVE can perform format-specific identification, validation and characterisation for supported formats.

But a validation result must be interpreted carefully. “Valid” does not automatically mean authentic, complete, safe, accessible, semantically correct or suitable for long-term preservation. “Invalid” does not automatically mean useless. Validation is one evidence layer in a larger preservation decision.

The useful chain is:

IDENTIFY
→ VALIDATE
→ CHARACTERISE
→ INTERPRET AGAINST POLICY
→ PRESERVE / REPAIR / NORMALISE / HOLD / ACCEPT WITH EXCEPTION
→ RECORD THE DECISION

1. Identification and validation are different claims

The previous article, How File Format Identification Works, followed the route from extensions and signatures to PRONOM, DROID and stable technical identities. That route deliberately stopped before treating identity as conformance.

A recognisable header may be enough to say that a damaged file appears to be a PDF. It is not enough to prove that the PDF’s internal objects, cross-reference information, syntax and required relationships are all acceptable.

Question	Typical evidence
What is the file?	Extension, MIME type, byte signature, PUID, structural clues.
Is it well-formed?	Parsing succeeds according to the basic syntactic rules.
Is it valid?	Required semantic and structural constraints are satisfied.
Does it meet a profile?	Additional restrictions for a specific use or preservation policy pass.
Is it preservable?	Repository policy, dependencies, sustainability, significant properties and risk.

These questions build on one another, but they are not interchangeable.

2. Well-formedness comes before deeper validity

Many structured formats distinguish basic syntactic correctness from stronger validity.

At the simplest level, a parser needs to be able to read the object according to the grammar of the format. Delimiters must close correctly. Required structures must be discoverable. Byte sequences must occur where the specification expects them. Lengths, offsets and internal references must make sense well enough for the parser to proceed.

If that floor fails, the file may be malformed.

But successful parsing is not always enough. A file can be syntactically readable while violating stronger rules about permitted values, required metadata, internal relationships or profile restrictions.

This gives us a useful hierarchy:

RECOGNISABLE
→ PARSEABLE
→ WELL-FORMED
→ VALID AGAINST FORMAT
→ VALID AGAINST PROFILE
→ ACCEPTABLE UNDER REPOSITORY POLICY

3. A specification is the authority behind validation

A validator needs rules.

Those rules may come from an international standard, an openly published specification, an XML schema, a formal profile, a documented implementation or another authoritative technical definition. The quality of validation therefore depends partly on the quality and completeness of the rules that can be implemented.

This creates an important limit. Software does not validate “truth” in the abstract. It validates particular properties against particular rules.

A validator may prove that a TIFF structure conforms to the rules it implements. It cannot prove that the photograph depicts what its caption says. A PDF validator can test technical conformance. It cannot prove that the argument in the document is correct.

Validation is therefore powerful precisely when its claim is narrow.

4. JHOVE is a preservation-oriented validation framework

JHOVE — JSTOR/Harvard Object Validation Environment — is an established open-source framework used in digital preservation for format-specific identification, validation and characterisation.

JHOVE uses modules for supported formats. A module can identify a candidate format, parse the object, report validity and well-formedness states, and extract technical properties. The framework’s preservation value is not that it produces a single green or red light. It produces structured technical evidence that can be interpreted by a repository workflow.

A simplified route is:

FILE
→ FORMAT MODULE
→ PARSE
→ TEST RULES
→ REPORT STATUS
→ REPORT ERRORS / WARNINGS
→ EXTRACT PROPERTIES
→ REPOSITORY POLICY

The last arrow matters most. Tools report observations. Institutions decide consequences.

5. “Valid” is always valid against something

People often speak about valid files as though validity were a universal property. It is more precise to say that an object is valid against a specified rule set.

A document may conform to the broad PDF specification but fail a narrower archival profile. An XML document may be well-formed XML but invalid against the schema expected by a particular application. An image may satisfy the TIFF specification while using features a repository’s preservation policy refuses to accept.

The complete statement should therefore preserve the target:

OBJECT X
VALIDATED BY TOOL Y VERSION Z
AGAINST RULESET / MODULE / PROFILE R
AT TIME T
RESULT = ...

Without the rule set, “valid” loses much of its evidential meaning.

6. Profiles deliberately make formats narrower

A general-purpose format may permit many features. A preservation community may need only a safer subset.

That subset can be formalised as a profile. PDF/A is a familiar example: it constrains PDF for long-term preservation use. Other communities create profiles for imaging, geospatial data, audiovisual material, office documents and specialised scientific outputs.

The logic is:

GENERAL FORMAT
− UNSUITABLE OR UNSTABLE FEATURES
+ REQUIRED PRESERVATION CONDITIONS
= PROFILE

Profile validation therefore answers a more operational question than generic format validation: does this object satisfy the particular constraints chosen for this preservation or interchange job?

7. Validation errors have different consequences

Not every validation failure deserves the same response.

A repository should distinguish at least:

• fatal structural failure — the object cannot be parsed reliably;
• format non-conformance — the file violates a formal rule;
• profile non-conformance — the file is valid generally but not under the required profile;
• warning — unusual or risky construction that does not necessarily invalidate the object;
• unsupported feature — the validator cannot fully assess a property;
• tool limitation — the implementation does not cover the entire specification or case;
• policy exception — the repository knowingly accepts a non-conformant object because preserving the original evidence is more important than normalising it.

This is why a binary pass/fail dashboard can be misleading. Preservation decisions require consequence.

8. Invalid does not mean worthless

An invalid file may still be historically important, partly readable or uniquely evidential.

Imagine the only surviving digital manuscript from an author. Its structure is damaged, but most text can still be recovered. Rejecting it because a validator reports failure would confuse technical cleanliness with archival value.

A preservation repository may instead:

• retain the original unchanged;
• record the validation failure;
• create a repaired or normalised derivative;
• document every transformation;
• preserve both states;
• route the damaged original to specialist review.

The governing principle is do not destroy evidence merely to make the validation report cleaner.

9. Valid does not mean authentic

A technically perfect file can still be fraudulent, misattributed or historically misleading.

Validation examines technical conformance. Authenticity is a broader evidential judgement involving provenance, custody, identity, context and sometimes signatures or external corroboration.

FORMAT VALIDITY
≠ AUTHENTICITY
≠ HISTORICAL TRUTH
≠ CORRECT METADATA

This boundary is essential in archives because technical certainty can otherwise create unjustified confidence about content.

10. Valid does not mean complete

Complex digital objects often depend on several files.

Each individual file may validate perfectly while the collection is incomplete because a stylesheet, font, linked dataset, media asset, sidecar metadata file or external dependency is missing.

Validation therefore has at least two scales:

• file-level conformance — is this individual object structurally valid?
• package-level completeness — does the larger intellectual or functional object contain the components it needs?

A repository that validates only individual files may still preserve a broken whole.

11. Valid does not mean safe

Some formats legitimately permit active content, macros, scripts, embedded objects or links to external resources. A file can conform perfectly to the specification and still pose a security risk.

Security analysis and format validation should therefore remain separate controls.

VALIDATION:
Does the file obey format rules?

SECURITY ANALYSIS:
Could permitted or hidden behaviour harm systems or users?

One cannot substitute for the other.

12. Valid does not mean sustainable

A valid file may rely on an obscure proprietary ecosystem, external service, unsupported codec or disappearing implementation.

The Library of Congress Sustainability of Digital Formats work evaluates factors such as disclosure, adoption, transparency, self-documentation, external dependencies, patents and technical protection mechanisms. Those are not simply validation questions. They concern the probability that the format remains manageable through time.

So:

VALID TODAY
≠ EASY TO PRESERVE TOMORROW

13. Characterisation explains what passed validation

Two valid files in the same format can still be very different preservation objects.