GitHub Repository Citation in APA, MLA, Chicago and Harvard

Style rules checked October 23, 2026 · Next check by January 21, 2027 · AI-assisted source and citation checks; not human review

Examples in every style

Real versioned repository: Citation File Format

The maintainers' public CITATION.cff identifies nine creators, version 1.2.0, its release date and a version-specific DOI. This example cites that version, not the continually changing main branch.

Synthetic repository with no DOI

Illustrative metadata only, not an actual repository or tested tool: a named researcher releases version 1.4.2. No invented URL or DOI is supplied. The source details in this example are made up to show the format.

How the styles differ for this source

Edge cases

• A repository requests citation of a paper instead of the code. Read preferred-citation before copying the Cite this repository output. GitHub supports a preferred research-article citation, so that output does not necessarily identify the software version you used. Style guide. Applies to APA Style 7th edition, MLA Handbook 9th edition, Chicago Manual of Style 18th edition (notes and bibliography), Cite Them Right 12th edition (author-date/Harvard).
• A concept DOI and a version DOI are both supplied. Match the identifier to your claim. The CFF maintainers explicitly distinguish their all-versions concept DOI from the DOI for version 1.2.0; the worked example uses the latter. Style guide. Applies to APA Style 7th edition, MLA Handbook 9th edition, Chicago Manual of Style 18th edition (notes and bibliography), Cite Them Right 12th edition (author-date/Harvard).
• You quote one source-code file rather than use a whole package. Record the file name and a revision or commit. MLA's source-code discussion explains why a version or commit matters; that older eighth-edition article is supporting background, not mislabelled ninth-edition wording. Style guide. Applies to MLA Handbook 9th edition.
• The repository has no visible date. Do not replace a release date with the year you visited GitHub. Chicago's public web-source guide permits an access date when publication or revision dates are missing. Style guide. Applies to Chicago Manual of Style 18th edition (notes and bibliography).

Common mistakes

Calling GitHub the software author

The hosting platform and the people responsible for the code are different. Read the maintainer-supplied creator metadata.

Not this: GitHub listed as author for a named research team

Do this (APA Style 7th edition, reference list entry): Druskat, S., Spaaks, J. H., Chue Hong, N., Haines, R., Baker, J., Bliven, S., Willighagen, E., Pérez-Suárez, D., & Konovalov, O. (2021). Citation File Format (Version 1.2.0) [Computer software]. https://doi.org/10.5281/zenodo.5171937

Using the all-versions DOI while claiming a particular release

A versioned reference should identify the consulted release. The real CFF metadata explicitly separates those DOI meanings.

Not this: Concept DOI 10.5281/zenodo.1003149 labelled as the identifier for version 1.2.0

Example not displayed (Cite Them Right 12th edition (author-date/Harvard), reference list entry): Pinned software rendering omits actual version1.2.0 and software medium, although both exist in correct software CSL input and checked named institutional template.

Copying a paper citation and assuming it documents the code

The preferred item can be a paper. Keep paper attribution and software-version documentation distinct.

Not this: A journal article presented as the source-code release

Do this (MLA Handbook 9th edition, reference list entry): Chen, Maya. Survey Cleaning Notebook. Computer software. Version 1.4.2, 12 Apr. 2025.

Check before you cite

• Open CITATION.cff or the maintainers' citation instructions.
• Check whether preferred-citation identifies software, a paper or a dataset.
• Record the actual release tag or commit used.
• Distinguish a version DOI from an all-versions concept DOI.
• Preserve the creator list and do not substitute the hosting service.

Is this the right source type?

Start by deciding what you need to document: running a released package, inspecting an individual source file, or discussing a paper associated with the project. Those are not interchangeable research objects. Open the repository's citation file and compare its title, creators, version and identifier with the material you actually used. GitHub's citation box can be configured to prefer a journal article, so copying it without checking may acknowledge the paper while leaving your software version unidentifiable. The real Citation File Format example is useful because its maintainers explicitly provide both a concept DOI for all versions and a DOI for version 1.2.0. The example deliberately selects the version-specific identifier. If your analysis instead depends on a particular code change, retain the commit and file path in your notes; do not invent a numbered release. The second example is synthetic and has no DOI, showing why a missing identifier is a gap to document rather than a field to fabricate. None of this claims that the software was run or tested by this website.

Frequently asked questions

This page is part of our source type citation guide.