netCDF-C: the C library and utilities that hold the netCDF data model

The C implementation of a data model rather than a file format only

netCDF is described as an interface for scientific data access and a freely distributed software library that implements that interface, and the library also defines a machine-independent format for representing scientific data. The README is careful about the three parts: the interface, the library, and the format, and it is the combination that supports the creation, access and sharing of scientific data.

netCDF-C is the C implementation of that set, and this repository is the official one for the C libraries and utilities. The primary language is C.

The audience is broad but specific in practice. A climate or ocean model writes its output as netCDF, a data centre republishes it as netCDF, and an analyst opens it with one of the language interfaces. The C library is what sits under all of that, and it is also what you need if you are writing the model itself, or a plugin, or a tool that has to read a file with a layout the higher level libraries do not expose.

The `examples/` directory in this repository contains a C example set and a CDL example set, with a CMakeLists.txt and a Makefile.am alongside them, which tells you that the intended starting point for a new C program is to copy an example and build it, rather than to read a tutorial first.

The last push to the repository was on 2026-10-06, and the project is not archived. The recent release history shows v4.10.1 on 2026-07-09, v4.10.0 on 2026-02-25 and v4.9.3 on 2025-02-07, which is a steady cadence for a library that has been in use for decades.

Self-describing, network-transparent, direct-access and extendible

The README defines the format through four properties, and each one is a design decision that explains why netCDF files behave the way they do.

Self-describing means a netCDF file includes information about the data it contains, so a reader does not need a separate schema document to know the dimensions, the variables and their attributes. This is the property that makes the format usable across decades and across tools.

Network-transparent means the file is represented in a form that can be accessed by computers with different ways of storing integers, characters and floating-point numbers. The bytes on disk are defined by the format rather than by the endianness or the word size of the machine that wrote them.

Direct-access means a small subset of a large dataset can be accessed efficiently, without reading through all the preceding data. That is the property that lets a tool open a multi-gigabyte file and read one time slice. It is also the reason netCDF files are not streamable in the way a compressed sequence might be.

Extendible means data can be appended to a netCDF dataset without copying it or redefining its structure, so a model can extend a time dimension as it runs instead of rewriting the file each step.

Those four properties together explain the format's persistence. They are also the reason the format is not a general purpose container: a file that is self-describing, byte-defined, randomly accessible and appendable has a specific shape, and the shape is what the whole ecosystem of tools and libraries is built around.

One tree holding many backends: HDF5, HDF4, DAP and Zarr

The top level directory listing is unusually revealing about how much this library contains, and it goes well beyond a single format.

There is a directory for each storage backend: `libhdf5/` and `libhdf4/` for the HDF family, `libdap2/` and `libdap4/` for the DAP protocols, `libnczarr/` for the Zarr format, `libncxml/` for an XML representation, and `libncpoco/` for the POCO, portable components object model. There is also `liblib/`, which is the core library itself, and three source directories, `libsrc/`, `libsrc4/` and `libsrcp/`, which are the implementations for the classic, the version 4 and the parallel variants.

This is the single most important structural fact about the project for a user. netCDF-C is not just a reader and writer for one container. It is a front end that sits over several storage engines, including the HDF5 backend that most people mean when they say netCDF-4, the DAP backends for accessing data over a protocol, and the Zarr backend for the cloud object store layout.

Alongside the libraries come the utilities. The listing has `ncdump/`, `ncgen/` and `ncgen3/`, and the `examples/CDL/` directory suggests a text form, CDL, that can be generated from and compiled back into a file. The `nc_test/`, `nc_test4/`, `ncdap_test/`, `dap4_test/`, `h5_test/` and `hdf4_test/` directories are the per-backend test suites, and `nc_perf/` holds performance tests. There is a `fuzz/` directory, a `conda.recipe/` for the conda package, a `NUG/` directory for the netCDF User's Guide sources, and a `ctest_scripts/` directory for the test harness.

One directory deserves a note on its own: `h5_test/` exists next to `hdf4_test/`, and the README does not say whether HDF4 support is deprecated or merely less used. A reader who needs that back end should check the release notes rather than assume.

Building from source: CMake, autotools, or a Windows binary

The README does not put build commands in the repository. It points at the INSTALL file in the netCDF-C distribution, and then at three documents, describing the second as usually more up to date.

* [Building NetCDF with CMake](https://docs.unidata.ucar.edu/netcdf-c/current/netCDF-CMake.html)
* [Building NetCDF with Autoconf/Automake/Libtool](https://docs.unidata.ucar.edu/netcdf-c/current/netCDF-autotools.html)
* [Building or Getting Binaries for NetCDF on Windows](https://docs.unidata.ucar.edu/netcdf-c/current/winbin.html)

The repository layout supports all three routes. There is a `CMakeLists.txt` at the top level with `CMakeInstallation.cmake`, `PostInstall.cmake`, `config.h.cmake.in` and `nc-config.cmake.in` alongside it, plus a `cmake/` directory. There is the autotools side with `configure.ac`, `Makefile.am`, `acinclude.m4`, `lib_flags.am`, `libnetcdf.settings.in` and a `bootstrap` script. And the Windows route is a separate document about getting binaries, which is the practical answer on that platform.

Two consequences follow. First, there is a `nc-config` script generated in both build systems, with a `.in` template for each, and that is the standard way to discover the include paths, library path and the version of an installed netCDF, so it is the file to look for after an install. Second, the `config.h.cmake.in` and `config.h.cmake.in.old-works` pair shows a configuration header that has been through a redesign, and the two supported build systems do not always agree on defaults, which is a common source of subtle differences between a distribution package and a self-built library.

The two build systems are genuinely different in what they enable, and picking the wrong one is a known source of friction. The CMake route is the one the project documents as more current, the autotools route is the one that matches how many Linux distributions package the library, and the Windows binary route avoids the question entirely.

The C library is only one member of the netCDF family

The README is explicit that the current netCDF software provides C interfaces for applications and data, and that separate software distributions from Unidata provide the Java, Fortran, Python and C++ interfaces, which have been tested on various common platforms.

The links are worth following, because they show the split.

* [C library and utilities](http://github.com/Unidata/netcdf-c)
* [Fortran](http://github.com/Unidata/netcdf-fortran)
* [Java](https://downloads.unidata.ucar.edu/netcdf-java/)
* [Python](http://github.com/Unidata/netcdf4-python)
* [C++](http://github.com/Unidata/netcdf-cxx4)

The practical rule that follows is simple. If your program is in Python, you want netCDF4-python and not this repository. If it is in Fortran, there is a separate distribution with its own user guide. This repository is the C layer, and it is the layer the others are built on, which is why a change here can affect every language interface.

The documentation links make the same point in a second way. There is a language-independent User's Guide for netCDF, a netCDF-C tutorial, a Fortran-90 User's Guide, a Fortran-77 User's Guide, a netCDF-Java user guide and the netCDF4-python documentation. The format is one thing, documented once, and each binding has its own guide on top of it.

Two support channels are named for users. A mailing list, [email protected], exists for discussion of the interface and for announcements about bugs, fixes and enhancements, and comments, suggestions and bug reports go to [email protected]. For a format that predates most of the current toolchain, having a maintained mailing list and a dedicated support address is one of the more reassuring facts in the README.

Licensing, the COPYRIGHT file and what has to be checked

The licence field in the repository metadata says BSD-3-Clause, which is a permissive licence, and the README points elsewhere for the authoritative answer. Copyright and licensing information can be found on the Unidata site, as well as in the COPYRIGHT file that accompanies the software.

That distinction is worth respecting rather than skimming past. The `COPYRIGHT` file is in the top level of the repository, next to `LICENSE`, and the `CITATION.cff` file is there as well, which is the modern way to express citation metadata for a project that predates that convention. The README also links a copyright page on the Unidata site, so there are three places to check, which normally means the terms are not uniform across every file.

This is not legal advice, and for most users the practical question is narrower than licence compliance. It is whether the version of netCDF-C you link against carries obligations that the distribution you installed did not, for example when a system package and a self-built library differ in the files they ship. The netCDF-4 implementation incorporates HDF5, and DAP and Zarr backends pull in further third party code, which is the normal situation for a C library of this kind and is another reason to read the COPYRIGHT file rather than assume the single metadata field is the whole story.

On the version side, the release pattern is regular. A minor release, 4.10.0, in February 2026, was followed by a point release, 4.10.1, in July 2026, and before that 4.9.3 from February 2025. The repository also has a `RELEASE_NOTES.md` file, so the change log for a specific version is in the tree rather than only on a website, and the repository is not archived with a last push on 2026-10-06.

Where netCDF-C is the wrong tool

The first wrong case is the most common. If your work is in Python and you simply need to open a netCDF file, this repository is the wrong starting point. netCDF4-python is a separate distribution built for that, with its own documentation, and pulling in the C build, its dependencies and its configuration for a Python script is a lot of machinery for a data read.

The second wrong case is when the requirement is really about storage on object stores. The tree does contain `libnczarr/`, so netCDF-C can speak the Zarr layout, but if your data lives in an object store and the consumers are other Zarr tools, then a netCDF-shaped workflow adds a layer that buys you the C API rather than the storage format itself.

The third case is about the shape of the data. The four properties are the point and also the constraint. A file that must be read sequentially, compressed and written by many writers at once is a different problem, and netCDF's direct-access and extendible model was designed for a different one. Similarly, a project that wants a self-describing schema with nested groups and rich user defined types may find the classic model limiting, and the documentation for that is where the netCDF-4 reference is.

The last wrong case is organisational. The C library is the foundation under five other language distributions, and the repository contains per-backend test suites, a fuzzing directory, a conda recipe and two build systems. Adopting it means adopting a C build with its configuration surface, and that is a reasonable trade for a model or a service that needs the reference implementation, and an unreasonable one for a team that just needs to read a file.

The reasonable middle path is to use the language binding your programme is written in, and to reach for this repository only when you need the utilities, the backends, or the C interface itself.

Editorial conclusion

netCDF-C is the right choice if your code needs the reference netCDF implementation, the command line utilities for inspecting and generating netCDF files, or a build that includes the HDF5, DAP or Zarr backends in one library. It is the wrong choice if you only need to read netCDF files from Python, where the separate netCDF4-python distribution already wraps the library, or if your real requirement is a cloud object store format such as Zarr, where a netCDF-shaped workflow adds a layer you do not need. Verify first which build system your platform is best served by, since the project ships both CMake and autotools routes, and check the COPYRIGHT file rather than assuming the BSD-3-Clause field in the repository metadata is the whole story.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. Unidata/netcdf-c on GitHub