Where Does LibRedirect Store Mappings and Settings?
LibRedirect keeps frontend mappings and settings in per-profile browser extension storage, with export for moves.
Last updated
LibRedirect stores mappings in extension storage inside the active profile. Frontend choices per service, custom instances, and exceptions share that space. There is no user-facing config file.
New profiles redirect with sane defaults, so nothing breaks urgently. Custom instances for niche frontends need the export file. That JSON is small enough to version with dotfiles.
Where LibRedirect stores this, by platform
%LocalAppData%\Google\Chrome\User Data\Default\Extensions (per profile)
Mappings per profile. JSON export covers custom instances and exceptions. Built-in frontends update with the extension itself.
~/Library/Application Support/Google/Chrome/Default/Extensions (per profile)
Same model on Mac across Chromium and Firefox builds. Firefox keeps it under its Profiles tree. Prefer export over folder copies.
~/.config/google-chrome/Default/Extensions (per profile)
Chromium profiles under ~/.config and Firefox under ~/.mozilla. Same JSON workflow. No request log persists anywhere.
Frequently asked questions
How do I move LibRedirect settings to a new browser?
Export settings to JSON from the options, then import on the new profile. Custom frontends and exceptions travel in that file. Built-in mappings refresh with updates.
Do LibRedirect mappings sync between profiles?
No. Each profile holds its own copy in extension storage. The JSON export is the migration path. Fresh installs redirect with defaults immediately.
Notice an outdated path? Let us know.