Fortran JSON Interface Libraries for Scientific Computing

If you are choosing a Fortran JSON library today, `json-fortran` is usually the default pick for new work: it has current releases, modern Fortran APIs, packaging options, and strong documentation. `FSON` still matters when you are maintaining older Fortran 95 style code or want a smaller, pointer-based parser for lightweight configuration files.

That distinction matters in scientific computing. Most teams do not need JSON for bulk numeric arrays, but they often do need a reliable way to load run configuration, emit metadata, exchange settings with Python or web tools, and validate small structured payloads without adding fragile ad hoc parsers.

Quick Recommendation

What Scientific Users Usually Need

Search visitors landing on this topic are usually not looking for a generic definition of JSON. They need to answer a practical question: which library will fit the build system, compiler level, and data flow of my scientific code?

• Predictable configuration loading: simulation inputs, solver settings, and experiment metadata should be easy to validate and easy to diff in version control.
• Interop with other tools: JSON is useful when Python, web dashboards, CLI wrappers, or job schedulers need to exchange small structured payloads with Fortran.
• Build compatibility: compiler support for Fortran 2003/2008 features can determine whether a modern library is painless or frustrating to adopt.
• Reasonable failure modes: clear parse errors and explicit missing-key checks save time when debugging production runs.

Current Fortran JSON Library Landscape

In practice, most Fortran users comparing general-purpose JSON libraries still end up choosing between `json-fortran` and `FSON`. They overlap, but they are not aimed at exactly the same codebases.

Example: Reading Simulation Config with `json-fortran`

The modern `json-fortran` workflow is usually: initialize the object, load a file or string, retrieve values by path, then clean up. This is much closer to what most production scientific applications need than a purely conceptual parser example.

program read_config
  use json_module, only: json_file, json_RK
  implicit none

  type(json_file) :: json
  character(len=:), allocatable :: solver
  integer :: steps
  real(json_RK) :: dt
  logical :: found

  call json%initialize(compact_reals=.true.)
  call json%load(filename="config.json")

  call json%get("simulation.solver", solver, found)
  if (.not. found) error stop "Missing simulation.solver"

  call json%get("simulation.steps", steps, found)
  if (.not. found) error stop "Missing simulation.steps"

  call json%get("simulation.dt", dt, found)
  if (.not. found) error stop "Missing simulation.dt"

  print "(A,1X,A)", "solver:", solver
  print "(A,1X,I0)", "steps:", steps
  print "(A,1X,ES12.5)", "dt:", dt

  call json%destroy()
end program read_config

Two details matter here for real projects: the `found` flag lets you fail fast on missing keys, and the allocatable string avoids the silent truncation problems that fixed-length strings can introduce in legacy Fortran code.

Example: Lightweight Config Reads with `FSON`

`FSON` is attractive when you want direct path-based extraction and a smaller mental model. The path syntax is one of its most useful features for simple configuration files.

program read_input
  use fson
  implicit none

  type(fson_value), pointer :: cfg
  integer :: cells
  character(len=16) :: scheme

  cfg => fson_parse("input.json")

  call fson_get(cfg, "mesh.cells", cells)
  call fson_get(cfg, "solver.scheme", scheme)

  print *, "cells =", cells
  print *, "scheme =", trim(scheme)

  call fson_destroy(cfg)
end program read_input

That simplicity is useful, but remember that `FSON` is built around pointer-managed values. In long-running scientific applications, cleanup discipline still matters.

Build and Integration Notes

• `json-fortran`: current docs and README cover CMake and fpm, and the project also publishes Conda and Homebrew installation routes. That makes it easier to standardize across developer machines and CI.
• Compiler expectations: `json-fortran` depends on major Fortran 2003/2008 language features, so very old compiler stacks can be the deciding factor against it.
• `FSON`: the README documents Makefile, Meson, and CMake flows. It can be a cleaner fit when you want to drop a parser into an older build without adopting a more feature-rich framework.
• Interface shape: prefer `json-fortran` if you need to create and emit JSON, not just read it. Prefer `FSON` if simple extraction is the whole job.

Scientific Computing Caveats

• Use JSON for metadata, not heavy numerics: configuration, provenance, model settings, and service payloads are good fits. Huge dense arrays and checkpoints usually belong in HDF5 or NetCDF instead.
• Be explicit about missing keys: scientific runs should fail early when required parameters are absent or typed incorrectly.
• Watch string handling: allocatable strings are safer than fixed-length buffers when file contents are controlled by external tooling.
• Validate input before you debug Fortran: formatting and checking JSON first often exposes trailing commas, broken quoting, or malformed nesting faster than recompiling parser code.

Official References

These primary sources are the most useful starting points when you need current details beyond this guide:

• json-fortran on GitHub
• json-fortran documentation
• FSON on GitHub