MARC21 Validator

A MARC record can look readable in a text editor and still fail when it reaches Koha, another integrated library system, a migration script or a MARC processing application. The MARC21 Validator on VWS Online is designed to catch those problems before import. It checks the record structure rather than simply searching for a title field, and it separates true structural errors from warnings and cataloguing advisories so you can see which problems are most likely to stop a record from being processed.

You can paste MARCEdit MRK text directly into the validator or upload common MARC files, including binary MRC/MARC, MRK, MRK-style text and MARCXML. Optional Koha checks inspect each 952 item field independently, which is useful when you are preparing records for migration or testing an export before a bulk import.

What the MARC21 Validator checks

The validator performs several layers of checks. For binary MARC21 records it reads the Leader, record length, base address, Directory, variable fields, field terminators and record terminator. For MRK and MARCXML it validates the text or XML representation and converts the record into the same internal field structure before running field-level checks.

• Leader structure: checks the 24-character Leader and important MARC21 positions such as the indicator count, subfield identifier length and entry map.
• ISO 2709 structure: checks the declared record length, base address, 12-byte Directory entries, field boundaries and terminators in binary MRC/MARC files.
• Tags and fields: detects malformed tags, empty records and incorrectly represented control/data fields.
• Indicators: verifies that data fields have two indicator positions.
• Subfields: detects invalid or incomplete subfield delimiters and codes.
• Fixed fields: checks common fixed-length fields such as 008 and 005 for expected lengths.
• Common bibliographic signals: reports missing 001, 245/245$a, 1XX and 260/264 data at an appropriate severity instead of treating every absence as a structural failure.
• ISBNs: checks ISBN-10 and ISBN-13 values found in 020$a when they can be interpreted as an ISBN.
• Koha item data: when enabled, checks individual 952 occurrences for barcodes and common item fields, and identifies duplicate 952$p barcodes in the validation batch.

Errors, warnings and advisories are not the same thing

A useful MARC validator should not label every unusual record as invalid. MARC21 defines a record structure, while cataloguing practice and local ILS configuration add another layer of rules. This tool therefore uses separate result levels.

• Error: a malformed record structure or serious selected Koha conflict, such as an invalid Leader structure, broken binary Directory, malformed tag or duplicate item barcode in the batch.
• Warning: a likely record or import problem that deserves review, such as a malformed 008 length, missing 001, missing 245$a or a failed ISBN check digit.
• Advisory: a condition that may be perfectly valid depending on cataloguing rules or local practice, such as the absence of a 1XX main entry or a 952 item field when Koha checks are enabled.
• Pass: the validator did not detect a structural error in the checks performed for that record.

This distinction matters. For example, a MARC21 bibliographic record without a 100 field is not automatically invalid. A work may have a corporate main entry, a uniform title or no 1XX field at all. The validator therefore reports that condition as an advisory rather than pretending that MARC21 requires a personal author in every record.

How binary MARC21 validation works

Binary MARC21 is based on the ISO 2709 record structure. Each record begins with a 24-byte Leader. The Leader contains the total record length and the base address of the variable fields. Between the Leader and the variable fields is the Directory. Each Directory entry is 12 characters long: a three-character tag, a four-character field length and a five-character starting position.

The validator compares those values with the actual bytes in the uploaded record. It also checks that the Directory ends with the MARC field terminator, that each variable field ends correctly and that the complete record ends with the MARC record terminator. These checks help identify truncated exports, damaged files and incorrectly constructed MARC records that can otherwise be difficult to diagnose from the visible field text alone.

For the formal record structure, see the Library of Congress MARC 21 Record Structure documentation. The broader MARC 21 Format for Bibliographic Data is the authoritative reference for bibliographic fields and subfields.

Leader checks

The MARC21 Leader is not simply a label at the top of a record. Its positions tell software how to interpret the bytes that follow. The validator checks that the Leader contains 24 characters and reviews important structural positions, including the two indicator positions, two-character subfield identifier length and the standard MARC21 entry map 4500.

In binary files the validator also checks the record length in Leader positions 00-04 and the base address in positions 12-16 against the actual record. A record can display recognizable 245 or 100 fields and still be structurally broken if these positions point to the wrong byte offsets.

The Library of Congress Leader documentation explains the meaning of individual Leader positions and should be used when you need to interpret a specific value.

Validating MARCEdit MRK records

MRK is a human-readable text representation widely used with MARCEdit. A typical field begins with an equals sign, a three-digit tag, two spaces, two indicators for data fields and then coded subfields. A simplified example is:

=LDR  00000nam a2200000 i 4500
=001  12345
=100  1\$aSmith, John
=245  10$aExample title :$bsubtitle.
=264  \1$aLondon :$bExample Publisher,$c2026.

The validator checks malformed tags, missing indicator positions, incomplete subfield delimiters and data that appears outside coded subfields. It also accepts continuation lines, but reports them as an advisory so you know that the text was joined to the preceding field.

If you are generating records from spreadsheets, you can use the Excel to MARC Converter for Koha Libraries and then validate a small MRK export here before moving to a production import.

Validating MARCXML

MARCXML represents MARC21 records as XML elements such as <leader>, <controlfield>, <datafield> and <subfield>. The validator first confirms that the XML is well formed, then checks tags, indicator attributes and subfield codes. It supports MARCXML documents that use the standard namespace because records are located by their local element names rather than by assuming an unqualified XML document.

The XML parser does not turn schema validation into cataloguing validation. A well-formed MARCXML file can still contain weak or incomplete bibliographic data. That is why the second stage of the validator runs common MARC field checks after the XML structure has been parsed.

Checking 008 and other fixed fields

Field 008 contains 40 character positions whose meaning depends partly on the type of material. This validator checks the basic 40-character length because an unexpected length is a strong sign of a damaged or incorrectly generated record. It does not pretend to validate every material-specific position against every possible cataloguing scenario. If you need a complete interpretation of an 008 position, compare the record with the relevant section of the official MARC21 bibliographic documentation.

Field 005 is also checked for its normal 16-character timestamp form when present. These checks are reported as warnings rather than structural ISO2709 errors because they describe field content, not whether the binary record can be read.

245, 1XX and publication fields

The validator checks for a title statement because a missing 245 or empty 245$a is usually something a migration team should investigate. It deliberately labels this as a bibliographic warning rather than claiming that a missing title field makes the ISO2709 byte structure invalid.

The same principle applies to main-entry fields. If no 100, 110, 111 or 130 field is found, the tool shows an advisory. That record may still be valid. Likewise, a missing 260 or 264 publication field may be appropriate for some resource types. The purpose of these messages is to direct a cataloguer to records worth reviewing, not to replace cataloguing rules with a simplistic checklist.

ISBN validation in MARC 020$a

When the validator finds an ISBN in 020$a, it applies the ISBN-10 or ISBN-13 check-digit calculation. A failed check digit is shown as a warning. Qualifiers such as binding information can remain in the MARC subfield; the validator attempts to isolate the ISBN portion before checking it.

If you are cleaning a list of identifiers outside MARC, use the dedicated ISBN Validator. Keeping the ISBN check separate from MARC editing is useful when the same identifiers also appear in acquisition spreadsheets, repository metadata or supplier data.

Optional Koha 952 validation

Koha commonly stores item/holding information in repeated MARC21 952 fields. One bibliographic record may therefore contain several 952 occurrences, each representing a different physical or item-level copy. The validator keeps those occurrences independent. It never combines a barcode from one 952 with the branch or item type from another.

When Koha 952 item checks are enabled, the tool reviews common item subfields including 952$a, 952$b, 952$p and 952$y. A missing barcode is a warning, while missing home library, holding library or item type values are advisories because exact import requirements depend on the local Koha framework and migration method. Duplicate non-empty 952$p barcodes within the same validation batch are treated as errors because item barcodes normally need to be unique.

The validator cannot know whether a code such as MAIN, BK or a shelving location exists in your Koha database. Those values must be checked against your own branches, item types and authorised values. For Koha-specific import preparation, also use the Koha MARC Import Validator and the Koha Migration Readiness Checker. The official Koha documentation should remain the final reference for the Koha version you are running.

MARC-8 and UTF-8 character encoding

Character encoding deserves special care during MARC migrations. A binary MARC record whose Leader declares UTF-8 is decoded as UTF-8 and invalid byte sequences are reported. When non-ASCII bytes appear in a record that does not declare UTF-8, the validator warns that the file is likely using legacy MARC-8. It can still inspect the byte-level record structure, but it does not pretend to transliterate MARC-8 characters into Unicode.

If a MARC-8 warning appears, review the record in MARC-aware software and convert the file to Unicode before relying on character-level comparisons. This prevents a structurally valid file from being mistaken for a clean Unicode migration source.

How to use the MARC21 Validator

1. Paste one or more MARCEdit MRK records, paste MARCXML, or choose a supported MARC file.
2. Leave Koha 952 checks off for general MARC21 validation, or enable them if the records are being prepared for Koha.
3. Select Validate MARC21.
4. Review errors first, because they indicate malformed record structure or serious selected Koha conflicts.
5. Review warnings next and decide whether the field data needs correction.
6. Read advisories in the context of the resource type and your local cataloguing policy.
7. Use the result filters to focus on one severity level.
8. Download the CSV validation report if you need to share or track corrections across a batch.

For a large migration, start with a representative sample rather than validating and importing everything at once. Fix the patterns that repeat across the sample, regenerate the source data, and then validate a larger batch.

Example: why structural validation matters

Suppose an MRC file contains a title that appears correctly when extracted by a loose text script. If the Directory says the 245 field begins at the wrong byte position, a standards-aware MARC reader may reject the record or interpret the following field incorrectly. A simple search for “245” would miss that problem. This validator checks both the visible field content and the binary offsets that define where the field actually lives in the record.

Conversely, suppose a record has no 100 field. A naive validator might call the record invalid. This tool instead reports an advisory because the absence of a personal-name main entry can be legitimate. Better validation means being strict about the structure and cautious about cataloguing judgments.

Related MARC and Koha tools

Validation is usually one step in a larger data-cleaning workflow. Use the MARC21 Record Builder when you need to construct and inspect a record manually. Use the MARC to Excel Converter when you need to audit MARC fields in a spreadsheet or expand repeated Koha 952 items into separate rows. Use the Excel to MARC Converter when your source catalog data begins in a spreadsheet.

If MARC21 itself is new to you, read MARC21 Explained for Beginners before making large mapping decisions. Understanding the difference between control fields, data fields, indicators and subfields makes validation reports much easier to interpret.

Privacy and file handling

The MARC validation logic runs in the browser. The selected file is read by the page so that the validator can inspect it; the validation workflow does not intentionally upload the MARC source file to VWS Online for processing. This design is useful for library data, but you should still avoid placing confidential patron information or other unnecessary personal data in test records. Bibliographic records and item exports should be minimized to the data required for the task.

Limitations of automated MARC validation

No general online validator can know every local cataloguing rule. A record may be structurally correct and still use the wrong authority heading, classification number, subject vocabulary, branch code, item type or acquisition value. The tool also does not replace a complete MARC21 field-by-field profile for every material type. Its purpose is to detect objective structural faults and high-value common problems, then make the remaining human review more focused.

For production migration work, keep the original export, create a corrected copy, validate a small sample, import into a test environment and compare the resulting bibliographic and item records with the source system. A clean validation report is an important checkpoint, not a guarantee that every cataloguing decision is correct.

Frequently asked questions

Which MARC formats can I validate?

You can validate pasted MARCEdit MRK or MARCXML and upload binary MRC/MARC, MRK, MRK-style TXT, XML or MARCXML files.

Does the validator check the binary MARC Directory?

Yes. For MRC/MARC files it checks the Leader, base address, 12-byte Directory entries, field boundaries, field terminators and record terminator.

Does a missing 100 field make a MARC21 record invalid?

No. A 1XX main-entry field is not appropriate for every record. The validator reports its absence as an advisory rather than a structural error.

Can it check Koha 952 item fields?

Yes. Enable Koha 952 item checks to review each 952 occurrence independently for common item data and duplicate 952$p barcodes.

Can the validator confirm my Koha branch and item type codes?

No. Those codes depend on your own Koha configuration. The validator can check whether common subfields are present, but local authorised values must be verified in your Koha installation.

Does the tool validate ISBN check digits?

Yes. ISBN-10 and ISBN-13 values found in 020$a are checked when the value can be interpreted as an ISBN.

What happens with MARC-8 records?

The validator can continue structural byte-level checks, but it warns when non-ASCII data appears in a record that does not declare UTF-8. Use MARC-aware software for MARC-8 character conversion.

Are my MARC files uploaded to the server?

The validation logic reads and processes the selected file in your browser and does not intentionally upload the MARC source file to VWS Online for validation.