ADIF Explained: Moving Your Log Between Programs Without Losing Data

Switching logging programs, merging years of contacts into one master log, or uploading to LoTW from a new piece of software all eventually run through the same file format: ADIF. It looks simple the first time you open one in a text editor — plain text, readable field tags — and yet log imports between programs go wrong constantly. Almost every one of those failures comes down to the same handful of predictable causes, all of which are avoidable once you understand what the format actually expects.

What ADIF Actually Is

ADIF, the Amateur Data Interchange Format, is a standardised way of encoding QSO records as plain text so that different logging programs can exchange log data without each one needing to understand every other program’s internal database structure. Rather than a rigid table format, ADIF describes each contact as a sequence of tagged fields, and the specification defines what each standard field name means, what values it can hold, and how records are separated from one another. Virtually every logging program in current use, from simple casual loggers to full contest suites, can both export and import ADIF, which is what makes it the closest thing amateur radio logging has to a universal file format.

Anatomy of an ADIF File

The header

An ADIF file typically opens with a header section containing information about the file itself — the program that generated it, the ADIF specification version it follows, and sometimes free-text comments — before an “end of header” marker signals where the actual QSO data begins. A missing or malformed end-of-header marker is a surprisingly common cause of an otherwise valid file failing to import correctly.

Field-tag format

Each piece of data in an ADIF file is wrapped in a tag stating the field name and the length of the value that follows, such as a callsign field or a date field, each holding exactly the data it announces. This self-describing structure is what lets a parser read the file without needing fields to appear in any fixed order — unlike Cabrillo, where field position in a line is everything, ADIF fields can generally appear in any order within a record as long as each one is tagged correctly.

Records

Each QSO becomes one record, a run of tagged fields ending with an end-of-record marker. A well-formed ADIF file is simply a header followed by any number of these records, one per logged contact.

ADIF vs Cabrillo: Different Jobs

It is worth being clear about how these two formats differ, since both show up constantly in contesting and both get called “the log file” informally. Cabrillo exists to describe one contest’s QSOs in exactly the structure that one contest’s scoring software expects — it is narrow and contest-specific. ADIF exists to describe your log in general, independent of any single contest or event, which is why it is the format used for moving a log between programs, uploading to LoTW or eQSL, and merging logs from different sources. A contest QSO usually needs to end up recorded in both formats eventually: Cabrillo for the contest submission, ADIF for your permanent, general-purpose log.

Common Fields You Will Actually Use

A handful of fields cover the overwhelming majority of what most operators need from ADIF: the other station’s callsign, the QSO date and time, band and frequency, mode, signal reports sent and received, and often the other station’s grid square, name, and any award-relevant information such as DXCC entity or a POTA park reference. Most day-to-day import problems trace back to a mismatch in how one of these core fields is represented between the exporting and importing programs, rather than to anything exotic in the file.

Why Log Imports Go Wrong

Field mapping mismatches

Some programs use slightly different custom fields for the same underlying information, or store optional data — like a POTA park reference or a contest-specific exchange — in a non-standard field that the importing program does not recognise. The standard core fields almost always map cleanly; it is the extra, program-specific extensions that most often get silently dropped or misplaced during an import.

Date, time and time zone issues

ADIF expects date and time values in a specific format, and critically, in UTC. A log exported from software that was, for whatever reason, configured to local time rather than UTC will import with every contact’s timestamp shifted, which can be difficult to notice immediately and painful to untangle afterward. Always confirm your logging software is actually recording and exporting in UTC before relying on exported ADIF for anything time-sensitive, such as an award application.

Mode naming inconsistencies

Digital mode naming is a frequent source of confusion, since some programs log a specific mode name directly while others log a broader mode category with the specific variant as a secondary field. A log that shows contacts correctly in the program that created it can still import into a different program with modes miscategorised if the two programs disagree about how a particular digital mode should be represented. This is worth spot-checking after any cross-program import, particularly for digital-mode-heavy logs.

Moving a Log Between Programs: A Practical Workflow

A few habits make cross-program migration far less error-prone than exporting once and hoping for the best:

• Export a small test batch first — a handful of recent contacts — rather than your entire log, and confirm every field imports correctly into the destination program before committing to a full migration.
• Check record counts before and after. If the destination program shows a different number of imported records than your source file contains, something was rejected or merged unexpectedly, and it is worth finding out why before trusting the new log.
• Spot-check dates, modes and grid squares specifically after import, since these are the fields most likely to silently misconvert even when the overall import reports success.
• Keep the original export file. If an import goes wrong, having the untouched original ADIF file means you can retry with a different program or a corrected mapping rather than starting from a possibly-corrupted destination log.

ADIF and LoTW/eQSL Uploads

Confirmation systems like LoTW and eQSL generally expect ADIF as their upload format, which is one more reason accurate ADIF export matters beyond simple program-to-program migration. An incorrectly formatted date, a missing band field, or a malformed callsign entry can cause individual contacts to be rejected during upload even when the rest of the batch succeeds, so it is worth reviewing any rejected-record report from these services rather than assuming a partial upload means the whole batch failed.

Program-Specific and User-Defined Fields

Beyond the standard fields the specification defines, ADIF also allows program-specific fields, conventionally prefixed to indicate they belong to a particular application rather than the core standard. These exist precisely because logging software regularly needs to store information the standard fields do not cover — a particular contest’s custom exchange element, an internal database identifier, or a feature unique to one program. The trade-off is that these fields are, by definition, not guaranteed to mean anything to a different program reading the file, which is exactly why data stored only in a program-specific field is the most common casualty of a cross-program migration. If a piece of information matters enough to keep permanently, check whether it has a standard ADIF field before relying on a program-specific one to carry it forward.

Validating an ADIF File Before You Trust It

Before importing a large or important log into a new program, a quick validation pass saves real trouble later. Open the file in a plain text editor and confirm the header and end-of-header marker are present and well-formed, spot-check a handful of records for obviously wrong values, such as a date far outside your actual operating history, and confirm the file’s character encoding matches what the importing program expects if you operate in a language with accented characters. Several free ADIF validation tools exist specifically to catch structural errors before they cause a failed or partial import, and running an unfamiliar or old export through one of these is a cheap insurance step compared with untangling a corrupted log afterward.

Common ADIF Mistakes

• Assuming every field will map perfectly between two different programs. Core fields usually do; program-specific extensions often do not.
• Not checking time zone settings before exporting. This is the single most common source of subtly wrong imported logs.
• Overwriting a working log with a bad import. Always import into a new or test log first, never directly over your only copy of an existing log.
• Ignoring character encoding issues. Names and comments with non-standard characters can occasionally get mangled between programs with different default text encodings, particularly on older software.
• Trusting an import summary without spot-checking actual records. A program reporting “import successful” confirms the file parsed without errors, not that every field landed in the field you expected — a quick manual check of a few records catches problems a clean import summary will not.

Common ADIF Fields at a Glance

Frequently Asked Questions

Can ADIF files be edited by hand if something is wrong?

Yes, since ADIF is plain text, careful manual editing with a text editor is possible for small fixes, though it is easy to introduce a formatting error this way, so always work on a copy and validate the result afterward.

Will I lose contest-specific data when exporting to ADIF?

Possibly, if that data lives in a program-specific field with no standard ADIF equivalent; core exchange information generally maps fine, but highly contest-specific metadata may not survive a round trip through ADIF and back.

Is a newer ADIF specification version always safe to use?

Generally yes for the well-established core fields, but if you are exchanging logs with older software, confirm it can actually parse the specification version your exporting program uses, since very old programs sometimes lag behind newer optional fields.

Why does my imported log show the wrong band for some contacts?

This usually happens when the source data only included an exact frequency and the importing program’s band-from-frequency conversion logic drew the boundary differently, particularly near the edges of a band segment.

Can I merge two ADIF files into one before importing?

Yes, many logging programs support importing multiple ADIF files sequentially into the same log, and dedicated ADIF merge tools also exist, though you should always check for duplicate contacts afterward.

Does ADIF support award-tracking fields like DXCC entity or POTA references?

Yes, the specification includes standard fields for this kind of award-relevant data, though whether your specific logging program populates and exports them correctly depends on that program’s own feature support.

The Bottom Line

ADIF’s plain-text, tagged-field design is exactly what makes it flexible enough to move logs between almost any two amateur radio programs — and exactly what makes small mismatches in time zone, mode naming or program-specific fields so easy to miss. Test with a small batch, check record counts, spot-check the fields most prone to silent errors, and keep your original export as a safety net. For the authoritative field definitions and specification versions, the official ADIF specification site is the primary reference every logging program developer works from.

If you are moving a log specifically to sort out QSL confirmations, see LoTW, eQSL and paper: confirming contacts today. And if you have not settled on a logging program yet, choosing a contest logger: N1MM+, Log4OM and DXLab compared covers how well each one handles import and export in practice. If your log’s GRIDSQUARE field is inconsistently populated across old contacts, grid squares and the Maidenhead locator system explains what a correctly formatted value should actually look like.