AnkiWeb
- Rating
- 0 (👍 0 · 👎 0)
- Updated
- 2026-08-08
- Anki versions
- 26.05~
- Description language
- en
AnkiWeb addon 1237174160
Keeps a local timeline of Anki note and note-type changes with diffs, snapshots, A→B comparison, pinning, and undoable partial restores.
Open on AnkiWeb GitHub Ask about alternatives
active
| Min Anki | Max Anki | Updated |
|---|---|---|
| 23.10 | 26.05+ | 2026-08-08 |
Loading…
Batch-updates multiple Anki note fields from CSV, matching rows via join keys, with dry-run, diff, and change logs for recovery.
Provides Git-based version control for Anki collections by exporting notes as Markdown, enabling diffs, selective import/export, conflict resolution, auto-snapshots, and remote push.
Cleans unnecessary spaces and furigana in Japanese Anki text while preserving needed reading spaces and HTML, with check, diff, fix, undo, and change log safeguards.
Provides a CodeMirror-based HTML/CSS source editor for fields and card templates, with syntax highlighting, search/replace, configurable themes/keymaps, version saving, diffs, and external editor support.
Delays or postpones updates for selected Anki add-ons to protect custom modifications, with an optional diff feature comparing folders before and after updates.
Edits card template HTML and shared CSS with live desktop/mobile previews, mirrors files for external tools, detects conflicts via three-way merge, and applies changes only after confirmation.
Read this in other languages: 한국어
Version History keeps a local timeline of observed changes to Anki notes (fields and tags) and note types (card templates and CSS). You can inspect per-field diffs, create named snapshots, and restore compatible content without leaving Anki.
This is a safety net, not an audit log of every intermediate keystroke. Automatic capture is debounced (1.5 seconds by default), so rapid consecutive operations can coalesce into one stored state. Old unpinned automatic note versions are pruned according to the retention settings.
History is stored locally per Anki profile under the add-on's
user_files/. It is not stored incollection.anki2, included in AnkiWeb sync, or shared between devices. A sync can trigger capture of the state that arrived, but the add-on cannot reconstruct a pre-sync state that was never captured. Create a full baseline before sync when that earlier state matters.
| Note history & per-field diff | Note type (template/CSS) diff | Tools menu |
|---|---|---|
![]() |
![]() |
![]() |
Media-file history exists in the source but is disabled in this release. The media-related configuration keys currently have no effect.
1237174160 (AnkiWeb page).Versions through 1.2.0 could leave history.db open while Anki tried to preserve
user_files/ during an update. Windows then reported PermissionError: [WinError 5] while renaming user_files to addons21/files_backup. Version 1.2.1 closes
its runtime before future installs and updates, but the old version cannot run that
new code before the first upgrade.
For that one-time transition:
See Anki's official add-on troubleshooting and safe-mode
instructions. If
you do not need the old history, deleting the old add-on and installing it again is
also acceptable: use the same Shift safe-mode run to delete it, restart normally,
and install code 1237174160 again. See Local data and backups before deleting
anything you may want to keep.
The default lazy mode starts recording new observed states without copying your whole collection. On the first profile open, the add-on offers a one-time full baseline. Declining suppresses the automatic offer, but the command remains at:
Tools → Note Version History → Baseline Entire Collection…
A full baseline is strongly recommended before bulk Find & Replace, large imports, full sync, or use of other add-ons that can modify many notes. It is required for Check & Repair Missing History… and is the only way to guarantee a stored pre-change state for notes that have never been tracked. The baseline reads the collection in the background and can resume if interrupted.
user_files/; it does not merge or
delete databases.| Target | Restored | Not restored / conditions |
|---|---|---|
| Existing note, whole version | Stored field values whose names still exist, plus tags | Does not reconstruct the historical note type, deck assignment, card states, scheduling, or review history. Stored fields with no current name match are skipped. |
| Existing note, selected fields | Only selected stored fields whose names still exist | Tags and every unselected/nonmatching field remain unchanged. |
| Deleted note, restore as new | Matching field values and tags into a new note in a deck you choose | The command is available only while that note's timeline is already open or otherwise reachable; there is currently no global deleted-note browser. The original note ID, cards, scheduling, and reviews are not resurrected, and the stored note type must still exist. |
| Existing note type | Front/back HTML of templates matched by exact template name, plus CSS | Does not add, delete, rename, or reorder templates; does not change fields/schema, sort field, note-type name, or scheduling. Missing names are reported and skipped/kept. This limited restore does not force a full sync. |
| Deleted note type | Earlier template/CSS versions remain viewable | It cannot be restored unless that note type still exists in the collection. |
Restores are undoable with Ctrl+Z. A restore is also recorded as a new history row so the action remains visible in the timeline. If the relevant card-template editor is already open, a note-type restore is loaded into that editor and takes effect when you press Save.
The Deleted filter applies inside the note timeline you have opened; it is not a collection-wide list of deleted notes.
Open Tools → Add-ons, select Version History - Notes and Note Types, and choose Config. The help pane documents every key; the defaults are:
auto (follow Anki; en and ko are available)Saving configuration immediately refreshes the settings cache and heartbeat.
auto_capture, debounce, and exclusions apply to subsequent work. Retention is
enforced at the next automatic maintenance opportunity (at most once per day), not
as soon as the Config dialog closes. A language change affects newly created UI;
restart Anki to reliably relabel the already-created Tools menu.
Turning auto_capture off pauses operation/sync/heartbeat capture, profile-open
catch-up and unclean-shutdown healing, and automatic retention maintenance. Manual
snapshots, the manual full baseline, Check & Repair Missing History…, history
viewing, and restore remain available.
The off period does not discard or advance the history scan marker/boundary, so the
first automatic scan after re-enabling may record the final observed state reached
while capture was off, but it cannot reconstruct that period's pre-change or
intermediate states.
Exclusions apply to automatic note capture only. They do not erase existing history and do not exclude note types themselves, manual snapshots, or the manual full baseline. Automatic-note retention does not prune note-type versions, manual snapshots, baselines, restore rows, deletion markers, pinned automatic rows, or the newest automatic row for a note. See the configuration reference for exact keys, ranges, and timing.
History is a schema-v2 SQLite database stored in a per-profile subdirectory of
user_files/. Notes are tracked by Anki GUID, and a profile setting keeps the same
database attached after a profile rename. The history database is separate from
the collection; only restore operations intentionally change the collection, via
Anki APIs.
collection.anki2, back up user_files/ separately if it matters to you.user_files/ when an add-on is
upgraded (official user_files documentation).
Version 1.2.1 also releases this add-on's Windows file handles before updates.user_files/ directory somewhere
safe before deleting the add-on. Anki 26.05 normally sends a deleted add-on
directory to the operating-system trash, but the trash is not a backup strategy.Default Windows locations:
%APPDATA%\Anki2\addons21\1237174160\user_filessrc\note_version_history\user_filesThe prod and dev directories therefore have separate configurations and separate history databases even when they use the same Anki base. They do, however, act on the same Anki collection when that base is shared.
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e ".[dev]"
.\.venv\Scripts\python.exe -m pytest
.\.venv\Scripts\python.exe -m ruff check src tests build.py
.\.venv\Scripts\python.exe build.py # -> dist/*.ankiaddon
Only __init__.py, scheduler.py, and ui/ import aqt; the remaining modules
are headless-testable.
Anki accepts a nonnumeric folder name for a local add-on, while an AnkiWeb add-on
uses its numeric ID. This lets the prod folder 1237174160 and a dev junction
note_version_history_dev coexist. Create the junction once, with Anki closed;
it remains valid until the junction is removed or the source path moves. Never
have both copies enabled at the same time.
Run this in Command Prompt (cmd.exe), replacing the source path if the
repository is elsewhere:
mklink /J "%APPDATA%\Anki2\addons21\note_version_history_dev" "C:\work\anki-version-history\src\note_version_history"
Or run this equivalent command in PowerShell:
cmd /c mklink /J "$env:APPDATA\Anki2\addons21\note_version_history_dev" "C:\work\anki-version-history\src\note_version_history"
The addons21 directory must already exist; starting Anki once creates the normal
base structure. See Anki's official add-on folder and symlink
guidance.
To switch versions:
1237174160.1237174160 (prod) and
note_version_history_dev (dev) is enabled. If their display names are the
same, use View Files to distinguish their folders.Do not point the junction at the numeric prod folder, install an .ankiaddon over
the junction, update the linked dev copy through Anki's package installer, or use
Anki's Delete action as a way to manage the source tree. To remove dev, close
Anki and remove only the junction itself; do not delete the source directory.
The same-base toggle is convenient for ordinary development, but it shares the
real profile and collection. Use a disposable base for package install/update,
uninstall, migration, full-sync, baseline/repair, and destructive restore tests.
Anki's -b option is an advanced startup option,
not a requirement for everyday source editing.
With every other Anki instance closed, start the isolated base:
"%LOCALAPPDATA%\Programs\Anki\anki.exe" -b "%LOCALAPPDATA%\AnkiVersionHistoryDev"
Always use the same -b argument for that base; the executable path can differ by
installation method. Build the .ankiaddon, then install it through the local
package installer in this isolated base. Do not add the everyday source
junction to it: two junctions that target the same source tree also share that
tree's user_files/, even though their Anki bases differ. A physically installed
package has its own user_files/ inside the disposable base and exercises Anki's
real install/update/uninstall lifecycle.
If an isolated base truly needs live-linked source, use a separate disposable
checkout or copy as the junction target so its runtime user_files/ is not the
one in your everyday working tree.
AGPL-3.0 © 2026 udonehn. Anki's anki/aqt packages are AGPL-3.0 and
this add-on links against them.