Moving Your Text Snippets to a New PC

Nobody thinks about this until the week they get a new laptop. By then the snippet library is a year old, has about eighty entries, and half of them exist because of a specific customer, a specific bug, or a specific phrase you got tired of typing in March.

The application is replaceable. The library is not.

Where the library lives

Text Replacements stores your snippets in:

%AppData%\TextReplacements\snippets.json

Paste that into the address bar of File Explorer and it resolves. It is plain JSON: you can open it in any editor, read it, diff it, and put it under version control if that is your habit.

A tool whose data is a single readable file in a known location is one you can back up, migrate and leave. A tool whose data is in a store you cannot find is one you are committed to.

Three ways to move it

Export and import, for a machine move

From inside the application, export to JSON or CSV, copy the file across, import it there.

Use this when you are moving to a new computer, handing a starter set to a colleague, or restoring after a clean install. It is the supported path, it survives version differences, and the CSV form opens in Excel if you want to review or edit in bulk first.

One behaviour worth knowing: existing shortcuts are not silently overwritten on import. If you import a file containing ;sig and you already have a ;sig, yours is kept. That makes importing a shared set into a personal library safe, and it means that if you want the incoming version to win you delete yours first.

Copy the file, with the app closed

Close Text Replacements on both machines, copy snippets.json across, start it again. This clones a library exactly, including anything the export path might normalise.

Do it with the application closed at both ends. Replacing a file a running process is holding is how you end up with a library that is neither the old one nor the new one.

A cloud folder, with conditions

You can keep the file in OneDrive, Dropbox or Google Drive and point both machines at the same copy, using a junction or by relocating the folder. People do this and it works.

Be clear about what you are getting, because it is not synchronisation:

• There is no merge. These services sync whole files. Add a snippet on the laptop and another on the desktop before either syncs, and one wins while the other lands in a conflict copy.
• Timing matters. The application reads the file when it starts and writes it when you edit. A sync arriving while the app is running may not be picked up until restart, and may be overwritten by the app's next write.
• Your snippets go into someone's cloud. For most libraries that is fine. If any snippet contains a client name, an internal URL or anything under an NDA, decide deliberately rather than by default.

The reliable version of this pattern is one writer and the rest readers. Edit on your primary machine, let it sync, treat the copies elsewhere as read-only. Dull, and it does not lose data.

Why there is no built-in sync

Text Replacements has no network code and no account. That is the same decision that means your snippets are not on anyone's server, no telemetry leaves the machine, and there is nothing to sign into.

Sync needs a server, an account, and a copy of your library somewhere you do not control. That is a legitimate product and it is not this one. The trade is stated plainly: you handle the file, and in exchange nothing about your text leaves your computer. If you want sync badly enough, the cloud folder above gets you most of it using a service you already trust with your files.

A backup habit

Twice a year, or after any session where you added several snippets:

1. 1. Export to JSON.
2. 2. Put the file somewhere that is itself backed up: a documents folder, a repository, a mail draft to yourself.
3. 3. Name it with the date. snippets-2026-09.json tells you what you are looking at in two years; snippets (1).json does not.

Sharing a set with a team

There is no shared team library, and at this price that is the honest state of things. What works in practice:

• Keep a canonical file in the repository or a shared drive: the team's standard sign-offs, the escalation template, the ticket-format snippet.
• Everyone imports it. Because import does not overwrite existing shortcuts, people keep their personal entries and gain the shared ones.
• Version the shared file with a date or number in the filename, and re-share when it changes. People import again, and the non-overwrite rule means only genuinely new entries land.
• Prefix shared triggers consistently, ;co- for company-wide say, so it is obvious later which entries came from the team set.

Bringing a library in from another tool

The target is a CSV or JSON file with a trigger and a replacement per row. Most tools can produce something close.

• AutoHotkey hotstrings are ::trigger::replacement lines. A search-and-replace in a text editor turns a hotstring file into a two-column CSV in a couple of minutes.
• Anything with a CSV export: reorder to trigger, replacement, import.
• Anything with a JSON or XML export: the shape differs per tool, but the content is two fields you can extract.

Two things do not survive any migration, and both are worth checking before you assume the move is done. Fill-in placeholders and cursor positioning are represented differently in every tool. Rich text formatting does not carry into plain-text expansion. Snippets that relied on either need rewriting rather than importing.

Frequently asked questions