# CrowdAnki: sharing Anki decks and notes through Git

> CrowdAnki is an Anki add-on that exports a deck and its notes as JSON and pulls them back in, and since version 0.6 it integrates closely with Git so that a shared deck lives in a repository with a history of every edit. It suits students and teachers who build decks together, and it suits them less when the deck's value is in Anki's scheduling data rather than in the cards.

**Stvad/CrowdAnki** — Plugin for Anki SRS designed to facilitate cooperation on creation of notes and decks.

- Repository: https://github.com/Stvad/CrowdAnki
- Stars: 643 · Forks: 52
- Language: Python
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/stvad-crowdanki

## What the plugin actually does: decks and notes as JSON

CrowdAnki is a plugin for Anki that allows users to import and export decks and notes and all relevant information in a JSON format, and the README states its main purpose plainly: to facilitate crowd-sourcing for Anki decks and notes.

That is a narrow description of a real workflow. Anki's native sharing story is a .apkg file, which is a package that merges into the collection and which nobody can diff. CrowdAnki replaces that with a directory you can put in Git: a JSON file describing the deck and its notes, plus a media directory with the images and sounds the notes reference.

The export is a normal Anki operation once the add-on is installed. You go to File, then Export, and choose the export format called CrowdAnki JSON Representation, and select the deck you want. What lands on disk is a directory whose name is the deck name, and that name matters later because the repository you create has to correspond to the directory that the export created.

The direction of travel matters too. The README's collaboration examples run through exporting a deck named DeckX, creating a GitHub account, creating a repository for the deck whose name matches the exported directory, and adding collaborators to it. Everything after that is Git, which is the point: the plugin supplies the format, and Git supplies the collaboration.

The project is a Python add-on with a crowd_anki/ package, and it is distributed through AnkiWeb under the shared info identifier 1788670778. It also ships a Chinese README, a checklist document, a supporters file and a sonar-project.properties file for static analysis, plus scripts for generating the user interface, fetching dependencies and packaging the plugin.

## The collaboration loop: pull, import, export, commit, push

The README's most useful content is the round trip, and it is worth stating in full because it explains both the plugin's design and its limits.

To publish changes, the sequence is: get the latest changes from GitHub, by pressing Sync in a GUI client or running git pull; import the deck, which combines the changes you made with the changes other people made; export the deck into the same directory where the repository is located, so that the export overwrites the media directory and the JSON file in the repository, or export elsewhere and copy the JSON file and the media directory over by hand; commit the changes with a message; and push them.

If you only want the latest changes from other people, you perform only the first two steps.

Two properties of that loop deserve emphasis. First, the merge happens inside Anki, not inside Git. Git never merges two versions of the same note for you; the import brings the remote changes into your collection, where Anki's own duplicate detection and note matching decide how a note that exists in both versions is handled, and the export then writes the combined result out. Second, the export must land on top of the repository directory, otherwise the JSON and the media files that Git is tracking are not the ones you just produced, and the commit records nothing.

That design is the reason the plugin works at all with Anki's data model, and it is also why the README is careful to mention the alternative of exporting elsewhere and copying the files across.

## The GitHub Desktop route and its Linux gap

The README documents two workflows, and the author is explicit about his reasoning for the first one.

His stated goal was to provide a user-friendly description of the collaboration workflow, so he looked through several GUI Git clients, and settled on GitHub Desktop as the most user-friendly client that works. The caveat he immediately records is that GitHub Desktop does not have a Linux version, which he describes as particularly sad since he uses Linux as his main operating system. He mentions having considered GitKraken for the tutorial and says it has problems that disqualify it for this purpose, while noting that Linux users may still want to consider it.

That honesty is useful, because it tells you the tool is aimed at people who do not want to use the command line, and it flags the one platform where that audience is underserved. The command line workflow exists for exactly those users.

In the desktop flow, the deck owner installs GitHub Desktop, logs in, creates a repository whose local path points at the imported deck and whose name matches the exported directory, adds the files with a commit message, and publishes. The README notes that in this case you do not need to create the repository in advance, because GitHub Desktop creates it for you. Collaborators install the same client, clone the repository from the GitHub page with the Clone or download, then Open in Desktop command, and import the deck. And if somebody only wants to use the deck rather than edit it, the README points at a separate path for importing a deck directly from the repository.

## The command line workflow, and what a pull request costs

The command line workflow is the same model with git commands, and the README gives them explicitly.

The owner installs Git, changes into the exported directory, and initialises a repository:

```bash
    git init
    git remote add origin git@github.com:<username>/<repository>.git
```

with the placeholder replaced by a real one, for example:

```bash
    git remote add origin git@github.com:Stvad/DeckX.git
```

The content is then added and committed, and the first push uploads it:

```bash
    git add *
    git commit -m "initial export"
```

```bash
    git push origin master
```

A collaborator clones the repository and imports the deck, and to publish their own edits they pull, import to combine, export over the repository directory, commit and push:

```bash
    git clone https://github.com/Stvad/DeckX.git
```

```bash
    git pull
```

```bash
    git add *
    git commit -m "new updates"
```

```bash
    git push origin master
```

The important detail for a team is that pushing straight to master works, but the README's structure suggests a review step is available: the same model, with the push replaced by a branch and a pull request, which is what most collaboration workflows require. The repository also carries a checklist.md, which is the obvious place to record who is editing which part of the deck, since two people editing the same note is the case where the import-time merge can surprise you.

## Snapshots, version compatibility and how the project is funded

Starting with version 0.6 the plugin also features a close integration with Git, and the README describes what that buys: an ability to automatically maintain history of edits for your decks, with the details in the snapshots section of the document.

The phrase to hold on to is automatically. Because every export overwrites the repository's JSON and media files, and because the plugin can be tied to the Git workflow, the history of a deck is the Git history, with the author attribution and the timestamps that come for free with commits. For a deck that a study group has been improving over a year, that history is the actual asset: it shows which notes were corrected, when a source was added, and when a card was replaced.

Version compatibility is the other practical thread. The recent releases tell the story in their release notes: v0.9.6 exists to allow functioning with Anki 26.09 and was published on 2026-09-18, v0.9.5 allowed functioning with Anki 23.10 in October 2023, and v0.9.4 allowed functioning with Python 3.11 in June 2023. Those three releases in a row are compatibility releases, which tells you that the plugin's largest maintenance risk is Anki's own release cadence rather than new features. The last push to the repository was on 2026-09-18 and the repository is not archived.

The project is MIT licensed and its README asks for sponsorship through a patron programme, with the reason given plainly: it helps the maintainer dedicate more time to the project. That is a normal arrangement for a solo-maintained add-on, and it also tells you who to ask when something breaks.

## Where CrowdAnki is the wrong choice

The first wrong case is a personal deck whose value is in the review history. The export is a representation of a deck and its notes, and the README describes the plugin's purpose as sharing decks and notes, not as a backup of a collection. If what you would lose is a year of scheduling history, a rating, a streak, this is not the tool to protect it.

The second wrong case is a real-time editing expectation. The loop is pull, import, export, commit, push. Two people working at the same time on the same note will both export, and one of the two commits wins for that note while the other contributor's edit is resolved by whatever Anki's import decides, not by a merge you can inspect in a diff. For a deck that is edited weekly by two people that is fine. For a deck edited hourly by a dozen, it is a source of lost work.

The third wrong case is a large media-heavy deck. The export writes the media directory as well as the JSON, so a deck with thousands of images puts thousands of binaries into the repository, and Git history on binary media grows without bound.

The fourth is a workflow that wants structured review rather than file review. Because the unit of collaboration is a whole-deck JSON file, a pull request on a shared deck shows a large JSON diff rather than one note change, and reviewing it in a hosting interface is not a pleasant experience.

The realistic alternative is to keep the deck in Anki and share .apkg files, which is simpler for one-off sharing and preserves more of Anki's own state, at the cost of no history, no diffing and no merging. The difference in approach is that CrowdAnki deliberately chooses the file representation over the package format so that ordinary version control can do the collaboration work, which is the right choice when the deck is a shared, long-lived artefact and the wrong choice when it is a personal collection.

## Conclusion

CrowdAnki is the right tool for a study group that wants one deck several people can improve, because the deck becomes plain JSON and media in a repository that Git can version and diff, and the plugin gives Anki an import format that preserves the structure. It is the wrong tool for a personal deck with a complex scheduling history, because the export carries the deck content and notes rather than a full account of review history, and it is the wrong tool for anyone who wants real-time editing rather than a pull, import, export, commit cycle. Verify first that the plugin version you install matches your Anki version, since recent releases exist purely to keep compatibility, and that you understand the merge behaviour before two people edit the same note.

## FAQ

### What does the CrowdAnki add-on do for Anki?

It lets you import and export decks and notes and all relevant information in a JSON format, so that a deck becomes a directory of JSON and media that can live in a Git repository. Its stated main purpose is to facilitate crowd-sourcing for Anki decks and notes, and since version 0.6 it has a close integration with Git that automatically maintains history of edits.

### How do I export a deck in the CrowdAnki format?

In Anki go to File, then Export, set the export format to CrowdAnki JSON Representation, and include the deck you want. The export creates a directory named after the deck, and the README notes that the repository you create has to correspond to that directory name.

### How do collaborators publish changes to a shared deck?

They get the latest changes first, by pressing Sync in the GUI client or running git pull, then import the deck to combine their edits with everyone else's, export it back into the repository directory so the JSON file and media directory are overwritten, commit the changes and push. If they only want the latest changes from others, the first two steps are enough.

### Which Anki versions does CrowdAnki support?

The recent releases are compatibility releases: v0.9.6 allows functioning with Anki 26.09 and was published on 2026-09-18, v0.9.5 allowed functioning with Anki 23.10, and v0.9.4 allowed functioning with Python 3.11. The plugin is distributed on AnkiWeb under the shared info identifier 1788670778.

### Do collaborators need a GUI tool or can they use the command line?

Both are documented. The README recommends GitHub Desktop as the most user-friendly GUI client for the workflow, while noting that it has no Linux version, and it also gives the full command line sequence with git init, git remote add origin, git add, git commit, git push, git pull and git clone.

### Under what licence is CrowdAnki released?

MIT, with the licence file in the repository root. The project is maintained by a single author, and the README asks for support through a patron programme so that more time can be dedicated to it.

## Sources

- [Issues](https://github.com/Stvad/CrowdAnki/issues)
- [License: MIT](https://github.com/Stvad/CrowdAnki/blob/master/LICENSE)
- [README](https://github.com/Stvad/CrowdAnki/blob/master/README.md)
- [Releases](https://github.com/Stvad/CrowdAnki/releases)
- [Stvad/CrowdAnki on GitHub](https://github.com/Stvad/CrowdAnki)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/stvad-crowdanki