earthaccess turns NASA Earthdata search into three lines of Python

The problem earthaccess solves is the metadata layer, not the download

NASA Earth science data is not one place. The same collection can sit in a DAAC archive, on a cloud bucket, or behind a different provider endpoint, and finding the right file means understanding a metadata repository before you can ask for the bytes. earthaccess was built around that gap during workshops run by NASA Openscapes, where the stated goal was easy access to Earthdata regardless of storage location. The library therefore treats the search as the hard part. Once a result set exists, the download step is comparatively plain: give it a destination folder. The intended users are scientists and analysts working with data at scale, often inside Pangeo style workflows where a notebook must fetch granules unattended.

Search sits on python-cmr, with provider resolution layered on top

The dependency list in pyproject.toml makes the architecture plain. python-cmr at version 0.10.0 or later provides the raw wrapper around NASA's Common Metadata Repository search API, and earthaccess builds on it rather than reimplementing CMR requests. What earthaccess adds is provider aware resolution, cloud hosting filters and richer result objects, which is where the convenience comes from: a collection short name is resolved to the providers that hold it, and files can be selected by whether they are hosted in the cloud. The rest of the dependency set is plumbing. tenacity and requests handle calls and retries, tinynetrc handles netrc parsing for credentials, s3fs and fsspec provide the filesystem layer for cloud hosted data, and pqdm gives parallel download support.

Authentication starts with login(), and the credential source is your choice

Every workflow in this library needs a free NASA Earthdata Login account, and the README says so before showing any code. earthaccess.login() prompts for the credentials interactively, or reads them from a .netrc file or from environment variables, which matters for unattended notebooks and scheduled jobs. The README does not document a token refresh or a service account path, so a long lived deployment depends on the stored credentials staying valid rather than on an in library refresh mechanism. The documentation also points to a dedicated authenticate page for the details, and the README lists a Zulip chat space and GitHub discussions as the places to ask when the credential flow does not behave as expected.

A first run is login, search, download, with the spatial filter inline

Installation is a single pip command, and the README asks for nothing else beyond a working Python environment.

python -m pip install earthaccess

The README then presents data access as three steps, and the worked example searches for an ICESat-2 land ice height product by short name, restricts it to a bounding box and a time range, and limits the number of returned granules.

import earthaccess

# 1. Login
earthaccess.login()

# 2. Search
results = earthaccess.search_data(
    short_name='ATL06',  # ATLAS/ICESat-2 L3A Land Ice Height
    bounding_box=(-10, 20, 10, 50),  # Only include files in area of interest...
    temporal=("1999-02", "2019-03"),  # ...and time period of interest.
    count=10
)

# 3. Access
files = earthaccess.download(results, "/tmp/my-download-folder")

The bounding box and temporal arguments are passed to the same call rather than filtered afterwards, so narrowing the search happens at the metadata API instead of on a large result set. The count of 10 keeps the example small; removing it returns the full set of matching granules.

virtualize() adds a Zarr interface without copying the archive

Streaming and virtual access are the parts of the library that extend past plain download. earthaccess integrates VirtualiZarr directly through earthaccess.virtualize(), which builds a virtual Zarr store over archival netCDF and HDF5 files without duplicating them, then presents the result as a virtual xarray Dataset. That means a workflow can keep using xarray style access against files that never land on local disk, which is the pattern cloud hosted analysis usually wants. The library also advertises streaming as a first class path alongside downloading, so the choice between pulling a granule locally and reading it in place is a parameter rather than a separate codebase.

Mission specific tools still win where depth beats generality

The README positions earthaccess against the rest of the NASA Earth science ecosystem with unusual candour. asf_search is described as search and access tailored to synthetic aperture radar data, while earthaccess is mission and domain agnostic. icepyx is ICESat-2 specific but uses earthaccess for authentication, so the two coexist rather than compete. earthdatalogin does the analogous authentication and access job for the R ecosystem. At the storage layer, fsspec and s3fs are general purpose filesystem libraries that advanced users can compose by hand, whereas earthaccess encapsulates the NASA specific authentication and cloud detection logic on top of them. The trade-off is explicit: one workflow for many missions, or a specialised tool with deeper parameters for one mission.

Python 3.12 is a hard floor, and the version moves on a calendar rhythm

The pyproject.toml declares requires-python of 3.12 or later, and the README calls 3.12 the minimum supported version, so anything older needs an interpreter upgrade before it can even attempt an import. The classifiers list 3.12, 3.13 and 3.14. Licensing is MIT under LICENSE.txt, which keeps the library straightforward to embed in research code and pipelines, and CITATION.cff plus a Zenodo DOI let a paper cite a specific release. Maintenance is active: the last push was on 2026-10-19, and recent releases include v0.19.0 on 2026-09-04, v0.18.0 on 2026-05-12 and v0.17.0 on 2026-04-02. The build uses hatchling with hatch-vcs, so the version is derived from tags rather than typed into the manifest by hand.

Editorial conclusion

Adopt earthaccess when your work pulls NASA Earth science granules regardless of where they are hosted, since one search call and one download call replace hand-written CMR queries and per-provider authentication. Skip it if you need mission-specific handling that asf_search or icepyx already do better, or if your environment is stuck on Python below 3.12. Verify first that the missions you need are reachable through the CMR index you query and that your institution allows EDL credentials in a .netrc file, since the README does not document a non-interactive token flow.

Frequently asked questions

Official sources

1. earthaccess-dev/earthaccess on GitHub
2. License: MIT
3. Project website
4. README
5. Releases