Private ADIF 3.1.7 preflight

ADIF Log Validator & Repair Assistant

Open or paste an ADI/ADIF or ADX log. Keep every readable record visible while checking syntax, field values, contact consistency, and probable duplicates. Review a separate, conservative repair preview before downloading anything.

Local log input

Open or paste an ADIF log

No file selected.

Files up to 8 MiB are read in this tab. Nothing is uploaded.

Paste ADIF or choose a log from your device.

Review before replacing a log. A clean structural result does not prove that a contact occurred, that a callsign or award reference is correct, or that an import target accepts every field. Keep the original and test repaired output on a copy.

Log text and files stay in this browser tab. ToolQuill does not upload contacts, callsigns, locations, or comments.

How the ADIF validation works

ADI fields use <FIELD:length[:type]>value, where the declared character length controls exactly how much data belongs to the field. Records end with <EOR>; an optional header ends with <EOH>. ADX represents the same model as UTF-8 XML with HEADER, RECORDS, and RECORD elements. The parser keeps readable records available when it can recover after a local problem.

Contact and duplicate checks

The audit checks supported dates, times, numbers, band names, common enumerations, BAND/FREQ agreement, and known MODE/SUBMODE parent pairs. It also reports the ADIF specification’s useful-QSO field guideline without treating it as a universal record requirement. Probable duplicates compare callsign, start date and time, band (including a band safely derived from frequency), mode, and submode; they are never deleted automatically.

What “safe repair” means here

Every proposed edit is deterministic and itemized. The assistant can normalize known case-insensitive values, remove separators from otherwise valid dates or times, repair import-only leading zeros in ADI lengths, and add a uniquely determined band. It does not guess callsigns, modes, dates, times, frequencies, locations, or which duplicate to keep. Unknown fields are preserved for forward and application-specific compatibility.

Validation boundary

This is a bounded preflight, not a complete ADIF conformance suite or logbook. It implements common field types and enumerations plus the current band table, but not every application-defined field, award-program rule, DXCC entity, contest rule, geospatial relationship, or version-specific semantic constraint. SUBMODE guidance is advisory in the standard. The page does not query callsign databases, upload contacts, sign logs, merge logs, remove duplicates, or certify an award submission.

Frequently asked questions

Why is an unknown field preserved?

ADIF permits application-defined fields and evolves over time. Dropping unfamiliar data would be riskier than retaining it and marking it for review.

Why does a duplicate remain in repaired output?

Matching core fields are evidence for review, not proof that two records are interchangeable. Comments, QSL state, station data, or application fields can differ.

Can I validate an ADX file?

Yes. Choose the file or force ADX in the format selector. The parser rejects DTD processing and does not fetch schemas or external entities.

Authoritative references

The released ADIF 3.1.7 specification defines ADI, ADX, data types, fields, enumerations, and band ranges. Its release resources page publishes the accompanying resources and explains the scope of its ADX schemas.

Validate another line-oriented data format · Browse ham radio tools