What this BagIt validator checks
The directory is evaluated as a BagIt 1.0 package under RFC 8493. The validator requires the exact two-line bagit.txt declaration, UTF-8 tag files, at least one payload manifest, visible files under data/, safe relative paths, strict manifest-line syntax, algorithm-sized hexadecimal checksums, and exactly one entry for every selected payload file in every payload manifest.
Local fixity verification
Supported SHA-1, SHA-256, SHA-384, and SHA-512 entries are recalculated with the browser's Web Crypto implementation and compared byte-for-byte with each manifest. Files are processed sequentially and cached by path and algorithm. Unsupported algorithms are never treated as verified. MD5 is permitted for legacy BagIt compatibility, but this page deliberately reports it as unsupported instead of introducing an extra cryptographic implementation.
Tag files and Payload-Oxum
If tag manifests are present, every listed tag file must exist and match its checksum. bag-info.txt fields and folded continuations remain visible; a present Payload-Oxum is compared with the selected payload byte count and file count. A tag manifest is not required, and it is not assumed to cover tag files it does not list.
Validation boundary
This page validates the selected unpacked files, not an archive container or a preservation workflow. Browsers do not expose empty directories, permissions, timestamps, symlinks, or files omitted from the folder selection. The validator does not fetch fetch.txt payloads, support every registered hash algorithm, validate a BagIt profile, inspect payload formats, repair manifests, or prove repository ingest readiness. For authoritative workflows, also validate with a maintained BagIt implementation and the receiving repository's profile.
Frequently asked questions
Can I choose a ZIP file?
No. Unpack ZIP, TAR, or other serialized bags first, then select the directory whose root contains bagit.txt. This keeps archive extraction and path-safety behavior outside the validator.
Why does fetch.txt stop a valid result?
A fetched payload is not among the selected local files. Because this privacy-first page makes no network requests, it cannot establish that held content exists, has the declared size, or matches a payload manifest.
Why is an extra payload file an error?
BagIt 1.0 requires every payload file to appear exactly once in every payload manifest. An unlisted file means the manifest is not a complete inventory for that algorithm.
Does a green result guarantee successful repository ingest?
No. Repositories can require a BagIt profile, particular metadata, allowed payload formats, filename rules, or additional checks beyond RFC 8493.
Authoritative format reference
The declaration, payload directory, manifest grammar, path escaping, checksum naming, completeness, and validity rules follow RFC 8493: The BagIt File Packaging Format (Version 1.0). The RFC requires BagIt 1.0 tools to support SHA-256 and SHA-512 and defines valid bags as complete bags whose listed checksums have been successfully verified.
Inspect MARC 21 records · Inspect a NetCDF header · Browse preservation tools