Move Your Espanso Snippets into a Chrome Text Expander

Espanso keeps every match as plain YAML in a folder on your own disk, so moving snippets into the browser starts with a file copy rather than an export dialog. Run espanso path base, take the files out of the match folder, and import them into SlashSnip: triggers, replacement text, and labels come across. Variables, forms, and extensions do not. Those are computed by a desktop process, and they stay where they already work.

None of this is an argument for dropping Espanso. It is open source under the GPL-3 license and it expands text across an entire desktop, including native applications that no browser extension can reach. What it cannot cover is a machine you are not allowed to install software on: a locked-down work laptop, a Chromebook, a borrowed desktop in a client's office. A browser expander sits beside it in those places, using snippets you have already written once.

Why is exporting from Espanso just copying a folder?

Espanso has no export screen and does not need one. Its configuration is a set of YAML files in an ordinary directory: ~/.config/espanso on Linux, $HOME/Library/Application Support/espanso on macOS, %AppData%\espanso on Windows. Open any of those files in a text editor and your snippets are right there in readable form, a trigger on one line and its replacement on the next.

That changes what migration means. With a hosted expander, an export is a request: you ask the product for your data and receive whatever shape the vendor chose to produce, if the feature is available on your plan at all. With Espanso the data was never anywhere else. Copying the folder is the export, and the file you walk away with is the same file the application reads every time it starts.

Readable storage, a diff you can inspect, no dependency on an export feature continuing to exist: the same properties make a browser expander of this kind predictable. The comparison of local-first and cloud storage models walks through what each side costs you.

Where does Espanso keep your matches?

Two folders live under that base directory, and only one of them matters for a migration. config describes how Espanso behaves, from backends to per-application settings to keyboard handling. match holds what it actually types. You want match.

Every YAML file in match is loaded automatically, with base.yml as the default starting point. One exception matters at copy time: files whose names begin with an underscore are not loaded automatically. Espanso treats them as pieces to be pulled in from elsewhere, not as standalone match files. They still contain matches. They sort to the top of a listing, where the eye skips right past them, and a migration that ignores them loses what they held with no error to warn you.

Moving the files

1. Ask Espanso where it lives. espanso path base prints the base configuration directory. Plain espanso path shows the full set of paths if you want to see the rest of them.
2. Open the match folder and read what is there. You are checking three things: how many matches you have, how many use anything beyond a trigger and a replacement, and whether the library is split across several files.
3. Copy every .yml and .yaml file, underscore names included. Copy, not move. Espanso keeps working on the desktop, and there is no reason to disturb it.
4. Keep that copy untouched and edit a duplicate. The original is your rollback point if the import goes somewhere unexpected. The snippet backup checklist covers why the unmodified original earns its keep more than the cleaned-up version does.
5. Import into SlashSnip. The import control in the dashboard settings takes .yml and .yaml files; a file is recognized by its extension, by a YAML content type, or by a top-level matches: key. This is an external file, not a SlashSnip backup, so the free-plan limits of 25 snippets and 5 folders apply and a large library will not land whole. Bring across a first batch, or check what the paid plans include first.
6. Type the triggers where you actually work. Not in a scratch page. In the compose window, the ticket form, the chat box. Type // followed by an imported shortcut, then open the browse menu with /// to see how the library looks from the inside.

Once the first batch behaves, keep the imported file somewhere you control. That same file is how the library moves to a second browser profile later, and the import and export documentation covers that route on the SlashSnip side.

What transfers and what stays behind

In the Espanso file	What arrives in SlashSnip
trigger	The snippet shortcut
triggers, written as a list	One snippet per entry — a match with three triggers becomes three separate snippets
replace, single line or a multi-line YAML block	The snippet body, with line breaks preserved
label	The snippet title
A match with no label	The title falls back to the shortcut, then to the opening characters of the body
vars, forms, extensions, and every other key	Not read by the importer
A match with no trigger at all	Skipped entirely

Two of those rows deserve a sentence each. Multi-line replacements written with YAML block scalars (the | and > styles, with their trailing modifiers) are read as text, so a six-line email template arrives as six lines instead of one run-on paragraph. The multi-trigger row changes arithmetic you may be counting on: forty matches where a dozen carry two triggers apiece arrive as fifty-two snippets, which matters when the free-plan cap sits at twenty-five.

The cursor marker converts as well. Where an Espanso match places $|$ to say "leave the caret here", the imported snippet carries {cursor}, which is the SlashSnip spelling of the same idea. You do not have to rewrite those by hand.

Now the boundary. Some matches assemble their replacement at insertion time — a shell command, a date extension, a form that asks you two questions first. None of those convert. The importer reads four keys and ignores everything else, so the machinery that made that match dynamic is not part of what lands in the browser. This guide deliberately shows no worked example of importing such a match: that outcome has not been recorded on a live run, and a plausible-looking example is worse than none. Anything Espanso computes for you is a reason to keep that match on the desktop.

Your triggers will not look the same

This is the part people discover with their fingers rather than their eyes. An Espanso trigger typically looks like :sig. After import it becomes //sig, because SlashSnip normalizes an incoming shortcut onto its own prefix. The snippet is intact, the name is intact, and the key sequence you have typed a thousand times is different.

It is a small change with an outsized first day. Two things soften it. The browse menu, opened with ///, finds a snippet by name while the new prefix is still unfamiliar, so nothing hides behind muscle memory you have not built yet. And the Espanso side is untouched, so :sig keeps working on the desktop exactly as before. One prefix per surface is less confusing than it sounds, because the surfaces differ: one is your own machine, the other a browser tab on someone else's.

Deciding what belongs in the browser

The useful question is not "how do I move everything", it is "which half of this library is browser work". Support replies, sales follow-ups, prompt skeletons, form boilerplate, addresses, disclaimers — those live in a browser tab and should be reachable there. The desktop half never needed to move: shell shortcuts, editor scaffolding, commands aimed at a specific desktop application, anything that leans on Espanso's dynamic layer.

The free-plan ceiling is a blunt instrument, but it does force that first pass: twenty-five snippets is roughly the library you use daily, as opposed to the one you have accumulated. Start there, live with it for a week, and see which Espanso habits followed you into the browser.

Sources

• Espanso configuration basics
• Espanso match basics
• Organizing Espanso matches across files
• Espanso command-line reference
• Espanso home page, stating the GPL-3 license
• SlashSnip import and export documentation