How to Cite Software and Code in Academic Papers

If your analysis depends on a specific Python package, a custom script you wrote, or a lab’s internal toolkit, that software is a source – someone else needs to be able to identify exactly what you ran to reproduce your results. Reviewers and journals increasingly expect a formal citation for code the same way they expect one for a dataset, and the rules borrow heavily from how styles already handle other non-traditional sources.

Why This Goes Beyond Formatting

Computational research has a reproducibility problem, and an uncited or vaguely cited piece of software is part of how that happens. A method section that says “we processed the data with a custom pipeline” tells a reader nothing they can act on. A citation that names the exact package, version, and archive location gives them something they could actually run themselves. Treating code as a citable source isn’t a formatting nicety layered on top of the science – for computational work, it’s part of describing the method at all.

The Example Software

We’ll cite this package in every style:

• Author: Claudio Satriano
• Software name: Seiscat: keep a local seismic catalog
• Version: 0.9.4
• Repository: Zenodo (archived from GitHub)
• Year: 2026
• DOI: 10.5281/zenodo.19707998

APA 7th Edition

Satriano, C. (2026). Seiscat: Keep a local seismic catalog (Version 0.9.4) [Computer software]. Zenodo. https://doi.org/10.5281/zenodo.19707998

Key rules:

• Author formatted like any other reference: last name, initials.
• Software name italicized, with the version number in parentheses immediately after.
• [Computer software] descriptor in square brackets, required by APA for any program, package, or script.
• Repository name stands in for the publisher.

MLA 9th Edition

Satriano, Claudio. Seiscat: Keep a Local Seismic Catalog. Version 0.9.4, Zenodo, 2026, doi.org/10.5281/zenodo.19707998.

Key rules:

• Author inverted (Last, First), same as any other MLA entry.
• Software name italicized as a standalone title.
• Version and repository fill MLA’s “version” and “publisher” core elements – no bracketed descriptor needed.

Chicago 18th Edition (Notes and Bibliography)

Footnote:

1. Claudio Satriano, Seiscat: Keep a Local Seismic Catalog, v. 0.9.4, Zenodo, released 2026, https://doi.org/10.5281/zenodo.19707998.

Bibliography entry:

Satriano, Claudio. Seiscat: Keep a Local Seismic Catalog. V. 0.9.4. Zenodo, released 2026. https://doi.org/10.5281/zenodo.19707998.

Key rules:

• Software name italicized, treated as a standalone titled work rather than an article inside a container.
• Version follows the title. The configured Chicago CSL style labels the release year explicitly.
• Full DOI URL at the end in both forms.

Harvard

Satriano, C. (2026) Seiscat: keep a local seismic catalog. Version 0.9.4. [Computer program]. Zenodo. Available at: https://doi.org/10.5281/zenodo.19707998.

Key rules:

• [Computer program] descriptor in square brackets – Cite Them Right’s term for software, distinct from APA’s “Computer software.”
• “Available at:” is required, but an access date isn’t – Cite Them Right only requires one when there’s no DOI or other stable identifier to point to instead.

IEEE

1 C. Satriano, “Seiscat: keep a local seismic catalog,” version 0.9.4, Zenodo, 2026. [Computer software]. Available: https://doi.org/10.5281/zenodo.19707998

Key rules:

• Initials before last name, matching every other IEEE reference.
• Software name in quotation marks rather than italics.
• Descriptor placed after the year, before the availability line.

Vancouver

1. Satriano C. Seiscat: keep a local seismic catalog [Computer software]. Version 0.9.4. Zenodo; 2026. Available from: https://doi.org/10.5281/zenodo.19707998

Key rules:

• No periods in the author initial (Satriano C).
• [Computer software] descriptor immediately follows the title, before the version.
• Semicolon between repository and year, matching Vancouver’s usual punctuation.

Quick Comparison Table

Special Cases

Software Without a DOI

Most code hosted only on GitHub, GitLab, or a personal site has no persistent identifier. Cite the repository URL directly and add an access date – code repositories change over time (or disappear) more often than published datasets do, so the date matters even in styles that otherwise skip it. Archiving a repository through Zenodo or Software Heritage before you submit your paper gives it a permanent DOI and a permanent copy, which is worth doing for any code central to your results.

Citing a Specific Version or Commit

If reproducibility matters – and for research code, it usually does – cite the exact version or commit hash you ran, rather than treating “the package” as a single stable entity. A script’s behavior at version 0.9.4 isn’t guaranteed to match a later release, and citing a moving target defeats the purpose of citing code at all. The FORCE11 Software Citation Principles are the closest thing to a shared standard on this, and most style guides’ version-number conventions trace back to that same logic.

Software Maintained by a Group or Organization

When a package has too many contributors to list individually, cite the maintaining organization or the lead maintainer listed in the repository’s citation file, and mention in your prose that it’s a collaborative project if that context matters to your argument. Many well-maintained open-source projects publish a CITATION.cff file specifically to settle this question – check the repository root before guessing at how the maintainers want to be credited.

Command-Line Tools and Notebooks Without a Formal Release

Not every piece of research code arrives as a versioned package with a changelog. A one-off analysis script or a Jupyter notebook you wrote for a single project still counts as software worth citing if someone else would need it to reproduce your work. Archive it the same way you would a larger package – a Zenodo deposit tied to a specific commit gives even a small script a permanent, citable version, rather than leaving it as an uncitable file sitting in a folder on your own computer.

Citing Your Own Code

If you wrote the software yourself as part of the research, cite it the same way you’d cite any other software you used, with yourself as the author. This comes up outside formal methods sections too – describing a tool you built is common in application materials like grad school personal statements, where citing your own prior work correctly matters as much as citing anyone else’s.

Common Mistakes

1. Citing “Python” or “R” as if the language itself needs a citation for ordinary use. Cite specific packages and scripts, not the general-purpose language, unless a style guide’s convention for your field says otherwise.
2. Skipping the version number. Without it, no one can tell which release of the software actually produced your results.
3. Dropping the bracketed descriptor – [Computer software] in APA, IEEE, and Vancouver; [Computer program] in Harvard. Without it, the citation reads like a book.
4. Leaving a GitHub URL uncited when the repository could have been archived with a permanent DOI instead. A live-only URL is a broken citation waiting to happen once the repository is renamed, moved, or deleted.
5. Listing every contributor by hand from the commit history. Check the repository’s own citation file first – maintainers often specify exactly how they want to be credited.

Try It with CiteTools

Once you have a DOI for an archived package – from Zenodo, Software Heritage, or a similar registry – CiteTools.io turns it into a correctly formatted software citation in any of the six supported styles, descriptor and version number included. If you’re assembling a BibTeX file for LaTeX alongside your citations, see our guide on exporting citations to BibTeX, Word, and LaTeX. For raw datasets that accompany the same project, see our guide on how to cite a dataset.