Petroware Logo

JSON Well Log Format

JSON Well Log Format


Most well log and drilling data in the oil and gas industry is trapped within tapes and disk files of ancient and hard to access data formats like DLIS, LAS, LIS, BIT, XTF, WITS, ASC and SPWLA.

These formats represents orphaned technologies and are outdated in all possible ways. Their syntax is overly complex, convoluted and awkward, available support software is limited, software tools are rare and documentation is poor or nonexistent.

But still: These are the main storage and communication media for well logging information in the 2018. The amount of data is immense and growing, as is the aggregate cost of maintaining and utilizing this information.

Introducing: The JSON Well Log Format

The JSON Well Log Format is a modern well log format designed for the future requirements of simplicity, compatibility, speed, massive storage, massive transmission, cloud computing and big data analytics. It overcome many of the deficiencies of existing well log formats:

  • Based on the JavaScript Object Notation (JSON) open standard (RFC 8259 and RFC 7493)
  • Text-based, lightweight and human readable
  • Full UTF-8 support according to the JSON standard
  • Date and time support through the ISO 8601 standard
  • Quantity and unit support based on the Unit of Measure Standard from Energistics
  • Built-in no-value support
  • Simple syntax consisting of collections of name/value pairs (objects) and ordered lists of values (arrays)
  • Fast: The simple syntax and streaming nature makes parsing extremely efficient
  • Well log semantics based on a limited set of well known keys to ensures consistency, compatibility and efficient processing
  • Compact type system
  • Supports depth and time based logging data
  • Supports single value and multi-dimensional (image) curves
  • Omnipresent parsers and generators for just about any system environment available
  • Existing ecosystem of NoSQL cluster database support with high volume storage, search and indexing, distribution, scalability and high performance analytics.


A JSON Well Log file consists of one or more log sets each containing logging meta data, curve definitions and the corresponding measurement data. The first curve listed is always the index curve.

This example contains a single log set with two one-dimensional curves:

     "log": {
       "metadata": {
         "name": "EcoScope Data" ,
         "well": "35/12-6S",
         "field": "Fram",
         "date": "2019-06-14",
         "operator": "Wellesley Petroleum",
         "startIndex": 2907.79,
         "endIndex": 2938.09,
         "step": 0.01
       "curves": [
           "name": "MD",
           "description": "Measured depth",
           "quantity": "length",
           "unit": "m",
           "valueType": "float",
           "dimensions": 1
           "name": "A40H",
           "description": "Attenuation resistivity 40 inch",   
           "quantity": "electrical resistivity",
           "unit": "ohm.m",
           "valueType": "float",
           "dimensions": 1
       "data": [
         [2907.79, 29.955],
         [2907.80, 28.892],
         [2907.81, 27.868],
         [2907.82, 31.451],
         [2907.83, 28.080],
         [2938.09, 27.733]

The JSON syntax can be efficiently parsed in any programming environment available. The well log semantics must still be parsed by the client code, but this is far simpler to do navigating in-memory data structures in the programming environment at hand, instead of dealing with external disk resources of obscure proprietary formats.

Logging metadata

The following metadata keys are defined as well known:
 name  Log name
 description  Log description
 well  Well name
 wellId  Unique well ID
 wellbore  Wellbore name
 field  Field name
 country  Country of operation
 date  Logging date as ISO 8601
 operator  Operator company name
 serviceCompany  Service company name
 runNumber  Run number
 startIndex  Value of the first index. Unit according to index curve.
 endIndex  Value of the last index. Unit according to index curve.
 step  Distance between indices if regularly sampled. Unit according to index curve. If log is time based, milliseconds assumed.
All metadata are optional.

In addition to the listed entries, clients may add any number of custom metadata in any form supported by the JSON syntax.

Curve definition

The following keys are used for curve definitions:

 name  Curve name or mnemonic. Mandatory. Non-null.
 description  Curve description. Optional.
 quantity  Curve quantity such as length, pressure, force etc. Optional.
 unit  Unit of measurement such as m, ft, bar, etc. Optional.
 valueType  Curve value type: float, integer, string, datetime or boolean. Non-null. Optional. float assumed if not present.
 dimensions  Number of dimensions. [1,>. Non-null. Optional. 1 assumed if not present.
Quantities and units should follow the Unit of Measure Standard from Energistics. To ease transition from legacy formats this is no requirement.

In addition to the listed entries, clients may add any number of custom curve data in any form supported by the JSON syntax.

Data types

Data types for curve data:
 float  Floating point decimal numbers  10.2, 0.014, 3.1e-108, 2.13e12, 0.0, null
 integer  Integer decimal numbers  10, 42, 1000038233, -501, null
 string  Text strings  "error", "final depth", "message 402", "", null
 datetime  Date/time specifications according to ISO 8601  "2019-12-19", "2010-02-18T16:23:48,3-06:00", null
 boolean  Logic states  true, false, null

Numbers should contain values corresponding to a double-precision 64-bit IEEE 754 binary format value. Integer values has the same internal representation in JavaScript and should be limited to 52 bits to ensure accuracy.

Also, numeric values that cannot be represented as sequences of digits (such as Infinity and NaN) are not permitted.


Clients may add any additional entries and structures to their well log files as long as it follows the JSON syntax. This can be done to communicate specific features or accomodate for custom meatadata etc. Note that the general informational value of such extensions is low. Some clients may understand the meaning of the extension, but in general such information is not fit for further processing.

To support convertion of legacy formats to JSON some standard extensions have been suggested.

This is the LAS parameter object that will capture general LAS parameter records of the form:

      <name>.<unit> <value> : <description>
This should be converted to JSON as follows:
      "<name>": {
        "value": <value>,
        "unit": <unit>,
        "description": <description>
For example:
   SwIrr  .V/V    0.30 : Irreducible Water Saturation
   Rshl   .OHMM   2.12 : Resistivity shale
   PDAT   .       MSL  : Permanent Datum
Converts to:
    "SwIrr": {
      "value": 0.3000,
      "unit": "V/V",
      "description": "Irreducible Water Saturation"  
    "Rshl": {
      "value": 2.12,
      "unit": "OHMM",
      "description": "Resistivity shale"
    "PDAT": {
       "value": "MSL",
       "unit": null,
       "description": "Permanent Datum"

Another common data structure for metadata is the DLIS set. This is a named entity with a number of attributes and a number of objects with one or more values for each of the attributes. A DLIS set has a binary representation within a DLIS file, but it can be viewed as a matrix as follows:

               attr1  attr2  attr3  ... attrn
      object1    v11    v12    v13        v1n
      object2    v21    v22    v23        v2n
      object3    v31    v32    v33        v3n
      objectm    vm1    vm2    vm3        vmn
This should be converted to JSON as follows:
      "setName": {
        "attributes": ["attr1", "attr2", "attr3", ... "attrn"],
        "objects": [
          "object1": [v11, v12, v13, ... v1n],
          "object1": [v21, v22, v23, ... v2n],
          "object3": [v31, v32, v33, ... v3n],
          "object1": [vm1, vm2, vm3, ... vmn]

For example:

    APWD      0.0 in   APWD25-AA      241408        0.0 kg
    ARDC      224.8 in ARC9D-BA       738           1270.0 kg
    MSSD900   14.5 in  SZR            FC-71545      68.0 kg
Converts to:
    "HzEquipment": {
      "objects": [
        "APWD": ["0.0 in", "APWD25-AA", "241408", "0.0 kg"],
        "ARDC": ["224.8 in", "ARC9D-BA", "738", "1270.0 kg"],
        "MSSD900": ["14.5 in", "SZR", "FC-71545", "68.0 kg"]

JSON Well Log Format examples

Log I/O

Petroware Log I/O is a library for reading and writing well log data files of different formats, including the JSON Well Log Format.

JSON access libraries exists for any programming environment and the Log I/O library is simply a convenience to make the API more comfortable to work with for the JSON Well Log Format. The library also contains high level API to handle LAS parameters and DLIS sets as described above.

Log I/O is a commercial product, but the JSON reader, writer and validator is free and available on GitHub.

About Petroware

Petroware AS is a software company within the data management, data analytics, petrophysics, geology and reservoir engineering domains.

Petroware creates highly advanced software components and end-user products that acts as a research platform within software architecture and scalability, system design, parallelism and multi-threading, user experience (UX) and usability analysis as well as development methodologies and techniques.

Petroware AS
Stavanger - Norway