Convert ADI to ADIJ and ADIJ to ADI with this online tool:

1. Overview

ADIF as JSON (ADIJ) is a proposed modernization of the Amateur Data Interchange Format (ADIF) using JSON structure. This format aims to maintain interoperability with existing ADIF data while providing better integration with modern software development practices. The new .adij file format strictly adheres to the JSON / ECMA-404 specification.

2. Specification

2.1 Document Structure

• An ADIJ document MUST be valid JSON as defined by JSON.org / ECMA-404
• The document MUST be a single JSON object containing:
  • An optional "HEADER" record object
  • A required "RECORDS" array of record objects
• A record is a json object containing one or more properties.
• Each record in the "RECORDS" array MUST be a JSON object containing at least one property (representing an ADIF field)
• All values MUST be JSON strings (no numbers, booleans, null, or nested objects/arrays)

2.2 Field Requirements

• All field names (keys) MUST be UPPERCASE. (json keys are case-sensitive)
• Field names MUST follow all ADIF naming conventions
• Field values MUST be strings, following JSON string encoding rules

2.3 Character Encoding

• The JSON standard requires UTF-8 encoding.
• For backward compatability, when converting ADIJ to ADI, field lengths MUST be measured in bytes, not characters/runes to avoid backward compatibility issues.
• The use of _INTL fields is deprecated in favor of encouraging UTF-8 encoding in the corresponding non _INTL field.

2.4 Media Types

The following media types are defined for ADIF variants:

• application/x-adif-json - ADIF in JSON format
• application/x-adif-adi - ADIF in ADI format
• application/x-adif-xml - ADIF in XML format

4. Implementation Notes

• Implementations MUST reject documents that do not conform to standard JSON syntax

5. A Bridge Too Far

• It is further proposed that the ADIF group depreciate the ADX file format. It is rarely used.
• It is further proposed that the ADIF group depreciate USERDEFn. ADIF is best viewed as a data transfer standard, not a database.

Sample 1

{
  "RECORDS": [
    {
      "CALL": "W9PVA",
      "QSO_DATE": "20250805",
      "TIME_ON": "201506",
      "BAND": "40M",
      "MODE": "SSB",
      "MY_POTA_REF": "US-0817,US-4566,US-4576,US-4573,US-4578@US-WY"
    }
  ]
}

Sample 2

{
  "HEADER": {
    "ADIF_VER": "3.1.5",
    "PROGRAMID": "K9CTS ADIF as JSON (ADIJ) DEMO"
  },
  "RECORDS": [
    {
      "CALL": "W9PVA",
      "QSO_DATE": "20250805",
      "TIME_ON": "201506",
      "BAND": "40M",
      "MODE": "SSB",
      "MY_POTA_REF": "US-0817,US-4566,US-4576,US-4573,US-4578@US-WY"
    },
    {
      "CALL": "K9CTS",
      "QSO_DATE": "20250806",
      "TIME_ON": "202522",
      "BAND": "40M",
      "MODE": "CW"
    }
  ]
}

API Endpoints

This website provides a simple API for converting ADIF data between ADI and ADIJ formats.

Convert ADI to JSON

Send an ADI document in the request body to convert it to JSON.

Convert JSON to ADI

Send a JSON document in the request body to convert it to ADI.

File Upload Conversion

Upload a file to convert between ADIF formats. The multipart form data must include a field named "file" containing the uploaded file.

• Upload an .adi file to convert it to .adij (ADIF as JSON)
• Upload an .adij file to convert it to .adi (ADIF format)

Response Codes

• 200 OK - Successful conversion
• 400 Bad Request - Malformed input or invalid format
• 415 Unsupported Media Type - Unsupported content type or file extension
• 500 Internal Server Error - Something went wrong

Example Requests

• ADIF.org
• JSON.org
• ECMA-404

• Why choose UTF-8?
  • The ADIF spec utilizes UTF-8 in XML. To keep it simple, we avoid introducing new encodings.
  • ASCII is fully forward compatible with UTF-8.
  • The JSON RFC requires the use of UTF-8.
  • Existing ADI parsers will be able to navigate a UTF-8 based structure corectly.
  • Existing ADI software MAY show "garbled" characters if they process an ADI file with UTF-8. This is an acceptable risk. They are unlikely to corrupt the data because they'll assume it as an ASCII byte stream and preserve the characters, unchanged.
• Why are all values stored as strings instead of being strongly typed?
  • ADIJ aims to replace the ADI data structures, which represent all data as ASCII strings.
  • This proposal aims to make converting between ADI and ADIJ seemless.
• Why doesn't ADIJ allow explicit data type definitions?
  • The type of the data can be inferred from the field name.
  • For example, CALL is always an ADIF "String"
  • For example, Frequency is always an ADIF "Number"
  • Likewise, APP_ fields rarely declare their data type and expect the processing program to know what to do if the program is aware of the APP_ field.
• Why should we depreciate the _INTL fields?
  • _INTL fields are only present in ADIF XML documents. Programs converting from XML to ADI must already account for this fact.
  • Removing _INTL fields makes converting between ADI and ADIJ very simple.
  • ADIF has NO backwards compatability guarantee. It DOES have a forward compatability guarantee.
  • ADIF has a long history of depreciating fields that have lost their relevance.
  • All modern programming languages support UTF-8
  • ADI Files produced by ASCII only software will work correctly with software implementing ADIJ. This meets the ADIF forward compatibility guarantee.
  • New, UTF-8 Files ingested by older software may display some strings incorrectly. They will, however, be able to correctly navigate the file structure because the length is defined as the number of bytes.

This section contains links to blogs and articles that provide analysis and feedback on the ADIF format. It is hoped that these will be useful in understanding ADIF strengths and weaknesses.

• Musings on ADIF File Format
• adif-json-protobuf
• adif-multitool - generates json, uses strong types
• ADIF Workgroup Discussions
• More articles to come as we do more research...