How to cite software in a paper

Most papers mention software somewhere. A sentence in the methods says the analysis was done "in Python" or "using R". A footnote has a URL. Sometimes the tool that did the hard work does not appear at all. None of this tells a reader which code produced the result, and none of it gives the people who wrote that code any credit.

Citing software properly fixes both problems. It is not a new kind of reference. It uses the same reference list, the same citation styles and the same identifiers as papers and datasets. This post covers what to include, how to make your own code easy to cite and where software citations belong in a manuscript.

Why cite software at all?

Because software is part of the method, and a method that cannot be identified cannot be checked. Two versions of the same package can give different numbers. A default can change between releases. If the paper does not name the version, a reader who gets a different result has no way of knowing why.

There is also a credit problem. Research software is often written by people whose careers are measured in citations. When their work is used and not cited, it is invisible to the systems that decide hiring, promotion and funding. Citing the software is the simplest thing an author can do about that.

What do the FORCE11 software citation principles say?

They say software should be cited on the same basis as any other research output. The principles were developed by a working group at FORCE11 and published in 2016. They are short and worth reading in full. In summary:

• Importance. Software is a legitimate product of research and should be cited in the reference list, not only mentioned in passing.
• Credit and attribution. Citations should credit the people who made the software.
• Unique identification. A citation should include an identifier that is globally unique and machine actionable.
• Persistence. The identifier and its metadata should outlive the software itself.
• Accessibility. The citation should help a reader reach the software and information about it.
• Specificity. The citation should point to the version that was used.

Most of the practical advice below follows from the last three principles. A good software citation is specific, persistent and leads somewhere useful.

What goes into a software citation?

The same core fields as any reference, plus a version. In practice that means:

Field	Example	Notes
Authors	Doe, A. and Rivera, M.	People or a project team, as the software asks to be credited
Title	example-analysis	The name of the software
Version	1.2.0	The release you actually ran
Year	2026	Release date of that version
Publisher or archive	Zenodo	Where the archived copy lives
Identifier	a version DOI	Or a SWHID, or a stable URL if nothing else exists

Put together in a typical author and year style, that reads something like: Doe, A. and Rivera, M. (2026). example-analysis (Version 1.2.0) [Computer software]. Zenodo. followed by the DOI. Your journal's style may order the fields differently. That is fine. What matters is that the version and identifier are there.

Which identifier should you use?

A DOI for the specific version, when one exists. Archives such as Zenodo issue a DOI for each release and a separate concept DOI for all versions. In a paper, cite the version DOI so the reference points to the exact code. Our guide on archiving code with a DOI walks through how those are created.

If there is no DOI, a Software Heritage identifier (SWHID) is a strong alternative because it is derived from the content and cannot drift. A repository URL with a commit hash is the fallback. A bare repository URL with no version is the weakest option, since the code at that address will change.

If you only have a version number and the software is installed from a package index, say so: name the package, the version and the index. That is still much better than "we used package X".

How does CITATION.cff help?

It lets the authors of a piece of software state, in one file, how they want it cited. Citation File Format is a plain YAML file named CITATION.cff placed in the root of a repository. GitHub reads it and shows a "Cite this repository" button with formatted references. Zenodo can use it for archive metadata, and other tools can convert it to BibTeX and similar formats.

A short example:

cff-version: 1.2.0
message: "If you use this software, please cite it as below."
title: "example-analysis"
version: 1.2.0
doi: 10.5281/zenodo.XXXXXXX
date-released: 2026-04-01
authors:
  - family-names: "Doe"
    given-names: "Alex"
    orcid: "https://orcid.org/0000-0000-0000-0000"
  - family-names: "Rivera"
    given-names: "Maria"

Two practical points. Update version, doi and date-released with every release, or the file will quietly hand out a wrong citation. And if the authors prefer that a paper be cited as well as, or instead of, the software, CFF has a preferred-citation block for that. When you cite someone else's software, check their repository for a CITATION.cff first and follow it.

Which dependencies should you cite?

Cite the software your results depend on in a way a reader would care about. A modern analysis can pull in hundreds of packages. Listing them all in the references helps nobody. A reasonable line to draw:

• Cite packages that implement the methods you report: the model fitting library, the alignment tool, the simulation code, the statistical test.
• Cite any software you wrote for the paper, archived and with its own identifier.
• Cite core tools when the project asks for it. Many scientific libraries publish a preferred citation.
• Do not cite generic utilities one by one. Record them in an environment file or lockfile and archive that with your code.

The full list of versions belongs in a machine readable file, not in prose. A requirements.txt with pinned versions, a conda environment file or a container definition does that job. Our post on reproducible environments covers the options. Then a single sentence in the methods can point to it.

Where in the paper should software be cited?

In the text where it is used, with a matching entry in the reference list. A citation that only appears in an acknowledgement or a footnote is easy to miss and is usually not picked up by citation indexes. Typical places:

1. Methods. Name each key tool and its version at the point you describe what it did, and cite it there.
2. Reference list. Give each cited package a full entry, formatted like any other reference.
3. Code availability statement. Cite your own analysis code here with its version DOI. See our guide to writing a code availability statement.
4. Supplementary material. Point to the environment file for the complete list of dependencies.

Some journals limit the number of references. If that bites, keep the software citations that matter for reproducibility in the main list and move the rest to the supplement, rather than dropping them.

What are the common mistakes?

• Citing only the paper that introduced a tool, when the version you used is years newer and behaves differently.
• Giving a version number with no identifier, or an identifier with no version.
• Citing the concept DOI, which resolves to the latest release, instead of the version you ran.
• Crediting a tool to its institution or company when the authors ask to be named.
• Pasting a URL into the text and leaving the reference list empty.

If the tool has both a paper and a software release, it is often best to cite both: the paper for the method, the software for the implementation you used.

What can you do this week?

Open the draft you are working on now and search the methods for package names. For each one that shapes a result, add the version and a reference entry. Check the project's repository for a CITATION.cff or a "how to cite" section and use what it gives you. Then add a CITATION.cff to your own repository, make a release and archive it, so the next person who uses your code can cite it correctly in under a minute.