How to Cite Software, Code and R Packages

Software is a citable research output, but most researchers were never taught how to cite it — there is no equivalent of the journal-article citation habit for a package, a script, or a repository. This guide covers the three things people searching for this actually need: how to cite an R package correctly, how to cite software or code in general when no formal citation exists, and how the CITATION.cff file (Citation File Format) that increasingly ships with research software actually works.

Quick reference: what to do, by scenario

Your situation	What to do
Citing an R package that ships a CITATION file	Run citation("packagename") in R and use the output it prints — that is the author-preferred citation.
Citing an R package with no CITATION file	Run citation("packagename") anyway — R auto-generates a citation from the package’s DESCRIPTION metadata (authors, title, version, year, URL) even without one.
Citing a GitHub/GitLab repository that includes a CITATION.cff file	Use the fields in that file directly, or let GitHub’s built-in “Cite this repository” button generate APA or BibTeX for you.
Citing a repository with no citation file at all	Build the citation yourself from what’s available: author/maintainer, software title, version number, year, and a persistent URL (ideally a DOI, not just the repo URL — see below).
Citing a specific version used in a study (for reproducibility)	Always include the version number, and archive that exact version (e.g. via Zenodo’s GitHub integration or Software Heritage) so the identifier resolves to the code as it existed when you ran it, not to whatever the repository has become since.

How to cite an R package

R has a built-in mechanism for this, so it is usually the most reliable of any language’s package ecosystem. Every installed package can be queried directly:

citation("packagename")

This returns the citation the package’s authors want used, printed in a ready-to-copy plain-text form (and, from R 4.x onward, also as a BibTeX entry). If a package includes an inst/CITATION file, citation() reads it and prints exactly what the authors specified — this is the authoritative source for how to cite that package, and it takes precedence over any style guide’s generic “software” template. If the package has no CITATION file, R does not leave you with nothing: it auto-generates a citation from the package’s DESCRIPTION file (the Authors@R field, title, version and year), which is why citation() always returns something usable even for the many CRAN packages that never added a custom file.

Worked example

Running citation("ggplot2") returns:

Wickham H (2016). ggplot2: Elegant Graphics for Data Analysis. Springer-Verlag New York. ISBN 978-3-319-24277-4.

Notice this isn’t a generic “software” citation — it points to the book the package authors specifically asked to be cited, which is a common pattern: many R packages have a companion paper (in JOSS, The R Journal, or elsewhere) that the maintainers prefer over a bare software citation, because it’s the version of record that gets indexed and counted. Always use what citation() returns rather than assembling your own citation from the package’s CRAN page, unless the package genuinely has no CITATION file.

Don’t forget the base R citation itself

If your methods or analysis depended on R itself, not just a package, cite R separately — running citation() with no arguments returns the current citation for the R software environment (base R has its own recommended citation, distinct from any package).

APA-style example built from a citation() result

Most citation styles don’t have an R-specific template, so you adapt the software/book template to the fields citation() gave you. For the ggplot2 example above, in APA 7th edition:

Wickham, H. (2016). ggplot2: Elegant graphics for data analysis. Springer-Verlag New York.

If the package has no companion book or paper and citation() returns only the auto-generated DESCRIPTION-based entry, the APA pattern is:

Author, A. (Year). packagename: Title from DESCRIPTION (Version X.Y.Z) [R package]. Retrieved from https://CRAN.R-project.org/package=packagename

How to cite software or code with no formal citation available

Most research software — a lab’s analysis script, a one-off tool, a fork of something on GitHub — doesn’t have a CITATION file or a companion paper. When that’s the case, assemble the citation from the same core elements every citation style ultimately needs:

• Author(s) — the individual(s) or organization credited as creator/maintainer.
• Title — the software’s name, and ideally a short description if the name alone isn’t self-explanatory.
• Version — the exact version or release tag used, not just “the latest version.” This matters more for software than for almost any other source type, because behavior genuinely changes between versions.
• Year — publication or release year of that specific version.
• Persistent identifier or URL — ideally a DOI (see below); a bare repository URL is the fallback, not the first choice, since URLs move and repositories get renamed, deleted, or force-pushed over.

This is essentially the FORCE11 Software Citation Principles checklist in practice: the working group’s 2016 recommendations (extended by the FAIR4RS Principles in 2022) argue software citations should be as complete, persistent, and machine-actionable as data or article citations — not an afterthought line reading “analysis was performed using [tool]” with no way to locate or verify what was actually run.

Get a DOI for code that doesn’t have one

A GitHub/GitLab URL identifies a live, mutable repository, not a fixed version — it can change or disappear. If you need a stable, citable identifier for a specific release (for a methods section, a data availability statement, or a data management plan), archive that version and mint a DOI for it. The two established routes:

• Zenodo’s GitHub integration — connect a repository, tag a release, and Zenodo archives that snapshot and registers a version-specific DOI (plus a “concept DOI” that always resolves to the latest version) via DataCite.
• Software Heritage — a universal archive of public source code that assigns persistent SWHIDs (Software Heritage identifiers) to specific commits, independent of any single hosting platform.

What is CITATION.cff (Citation File Format)?

The Citation File Format (CFF) is a plain-text, YAML-based file — conventionally named CITATION.cff and placed in a repository’s root or default branch — that holds human- and machine-readable citation metadata for software (and, since v1.2.0, datasets). It’s maintained collaboratively (with support from the German Aerospace Center’s Institute for Software Technology, the Netherlands eScience Center, and the Software Sustainability Institute) and is now widely adopted specifically because GitHub recognizes it natively: when a CITATION.cff file is present in a repository’s default branch, GitHub automatically surfaces a “Cite this repository” option on the repo’s landing page, generating APA text or a BibTeX entry from the file’s contents without the visitor needing to open or parse the YAML themselves.

A minimal CITATION.cff looks like this:

cff-version: 1.2.0
message: "If you use this software, please cite it as below."
authors:
  - family-names: Doe
    given-names: Jane
    orcid: "https://orcid.org/0000-0000-0000-0000"
title: "My Analysis Tool"
version: 1.2.0
doi: 10.5281/zenodo.1234567
date-released: 2026-01-15

If you maintain research software yourself, adding a CITATION.cff is the single highest-leverage thing you can do to make it properly citable — it takes GitHub’s citation prompt from generic (“cite the repository URL”) to specific (correct authors, ORCID iDs, version, and DOI), and it’s what reference managers increasingly look for when importing software metadata. A related, more software-engineering-oriented alternative is CodeMeta — a JSON-LD vocabulary for describing software metadata that some projects publish alongside or instead of a CFF file; the two overlap heavily in the fields they capture.

Frequently asked questions

How do I cite an R package in APA format?

Run citation("packagename") in R, then adapt whatever it returns to APA’s software/book template (author, year, italicized title, version if relevant, publisher or URL). See the worked ggplot2 example above.

What is software citation?

Software citation is the practice of formally crediting the software, code, or package used in research — author, title, version, and a persistent identifier — the same way a data citation credits a dataset, rather than mentioning a tool only informally in prose.

Do I need to cite code I only used briefly, like a single script?

If the software materially affected your results (an analysis package, a simulation tool, a processing pipeline), yes — cite it, including the version, so the analysis is reproducible and the authors get credit. Trivial, incidental tools (e.g. a text editor) generally don’t need a formal citation.

What’s the difference between citing software and citing a dataset?

The underlying logic is the same (author, title, version/date, persistent identifier), but software citation additionally emphasizes the exact version used, since software behavior changes between releases in a way that matters for reproducibility. See our companion guide on how to cite a dataset.

Does a CITATION.cff file replace a DOI?

No — they solve different problems. A DOI is a persistent identifier that resolves to a specific archived version of the software (typically minted via Zenodo or a similar repository). A CITATION.cff file is structured metadata describing how to cite the software, and it commonly includes a DOI as one of its fields once one exists.

Related CASRAI resources

• How to Cite a Dataset
• How to Cite Data: Formats and the Data Citation Principles
• Reproducibility Infrastructure: Workflows, Containers and Code Sharing
• RO-Crate: Packaging Research Data and Metadata for FAIR Reuse
• Dictionary: Software Citation (FORCE11 Working Group)
• Dictionary: FAIR4RS Software Citation Principles
• Dictionary: Software Heritage Archive
• Dictionary: Software Management Plan (SMP)
• Dictionary: Persistent Identifier (PID)

Last verified 2026-08-16 against citation-file-format.github.io (CFF specification and GitHub integration), the CRAN R Extensions manual (citation() and inst/CITATION behavior), and CRAN’s ggplot2 citation page.