Each data field is preceded by a field name and length
enclosed in angle brackets. The name and length are separated by a colon. The
field name may be in upper, lower, or mixed case. Case is insignificant. For
instance, CALL, Call,
or call are
equivalent. The length specification is ASCII text in display format, and may be
of any non-negative value. The data follows the closing angle bracket. For
example:

<CALL:6>WN4AZY

Records are made up of multiple fields and terminated with
<EOR> or <eor> as an end-of-record marker. For example:

Any number of characters of any value except <
may be added after a fields data or <eor>
and before the start of the next field. This is typically carriage returns
and/or linefeeds to make the file easier to read in a text viewer. For
example:

In this example, a newline is inserted in the
middle of each record, and two newlines are inserted at the end of each
record. This makes long records easy to read in a text editor.

Optional header information may be included before the
actual data in the file. To include optional header info, the first character of
the file must be something other than <.
Any amount of header info of any value except <eoh>
may be included. The header info must be terminated with <eoh>.
Any number of characters of any value except <
may follow <eoh>.
The first < after <eoh>
is the start of the first field of the first data record in the file. Here is an
example:

this data was exported using WF1B RTTY version 9,
conforming to ADIF standard specification version 9.99<eoh>

<call:4>aa1a...

If the first character of a file is <,
it is presumed to be the first field of the first data record.

The ADIF version may be included in the header info as
follows: <adif_ver:4>1.00
is included as part of the header specification, an importing program can easily
determine the ADIF version used to create the file. Note that this must not be
at the beginning of the header info, because <
as the first character indicates that there is no header.

It is important for the programmer importing ADIF data to
note that any number of characters of any value may follow the actual data in a
field. For example, carriage return/linefeed, or just a line feed. There is
nothing in the specifications to prevent an exporter from placing a comment
after the actual data. Therefore, after reading a fields data based on the
length specification, the programmer should read and discard characters until
the start of a new field (<)
or <eor> is
encountered.

There is no specification for the order in which fields
appear. They may appear in any order. Unused fields may be omitted entirely.
Therefore, each record will not necessarily have the same fields. The
specification does not prohibit a zero-length field, so those writing import
programs should allow for this.

There is no specification for field length or maximum
field length in the Physical Specifications. Unless there is a length
specification in the Field Definition, exporters simply export all data in their
field. Importers import as much data as their program can accept.

Note that while these examples have all been of simple
ASCII fields, the specification permits data of any type or length. It could be
easily used to transfer pictures or text documents, for instance.

Applications may define their own fields. To avoid naming
collisions, such fields must be named using the format

APP_{PROGRAMID}_{FIELDNAME}

where {PROGRAMID} is replaced by the string used in the PROGRAMID
field. An application whose PROGRAMID string is MONOLOG could thus define
the fieldAPP_MONOLOG_BIRTHDAY .

if it wished to capture the contacted operator's
birthday. To facilitate importing, display, and editing by other
applications, instances of application-defined fields should include the
optional data type indicator, as in