Profiles

--profile <name> picks how strictly producer-specific and stylistic findings are graded. The default is spec.

A profile re-grades severities. It never suppresses a check the spec requires — a MUST violation is still reported under every profile, even if lenient prints it as info.

The three profiles

spec (default)

WACZ spec plus wabac.js loader compatibility. An archive that exits 0 here is expected to replay correctly in ReplayWeb.page, bugs in wabac.js itself aside.

This is the profile to use when the question is “is this archive correct?”

browserhive

spec plus the stricter producer conventions of BrowserHive — for example that indexes/index.cdxj is stored plain, so a .cdxj.gz is rejected even when paired with a .idx.

Use it when the archive is known to come from BrowserHive and you want its house rules enforced too. On any other producer’s output it will report conventions that archive never agreed to follow.

Pinning the producer version

BrowserHive’s output changes between versions. Append @<x.y.z> and only the rules known to be correct for that version run.

wacz-validator-validate --profile browserhive@2.1.0 archive.wacz

Without a version, every rule runs, including the version-conditional ones — that is the previous behaviour, kept as the default.

A rule held back by a version mismatch is reported in skipped. It is not dropped silently: a reader who cannot tell “nothing wrong” from “not looked at” is being misled.

"skipped": [
  {
    "rule": "warc/recording-complete",
    "reason": "profile-version",
    "range": ">=1.11.0"
  }
]

The version is not checked against the archive

--profile browserhive@1.0.0 is taken at face value; nothing verifies that the archive was really produced by 1.0.0. datapackage.json carries a software field naming the producer and its version, but wacz-validator does not read it yet. The version is the operator’s claim.

lenient

Demotes every producer-specific and stylistic finding to info, leaving only the hard errors that break replay.

Use it to triage legacy archives, where the question is not “is this correct?” but “is this salvageable?”

Which rules a profile actually changes

The Rules table has a Profile overrides column showing exactly which rules are re-graded and to what. Rules with an empty cell behave identically under all three profiles.

That column is generated from each rule’s applicability declaration, so it is the authoritative answer — not a summary of one.

Exit codes

The profile affects the exit code only through severity: what counts as a failure is unchanged, but a rule demoted to info no longer contributes one. The mapping from report to exit code lives in @wacz-validator/protocol (exitCodeFor), shared by the CLI and the TUI so both agree.