Yougroup Blog
Sync Curated YouTube Lists Across Devices Without a Cloud Account
Four ways to keep curated YouTube lists current on every device without a cloud account, from manual export and import to Syncthing and WebDAV.
How to sync YouTube subscriptions across devices without a cloud account
Curated YouTube lists only work as a system if they follow you between machines. When your research channels, watched marks, and playback queues live inside one browser's extension storage, every device switch means rebuilding the setup by hand. Search for how to sync YouTube subscriptions across devices and most results assume you will accept a cloud account and a hosted service. If you curate locally precisely to avoid that, you need a different answer.
Local-first data sync is that answer: no hosted backend, no analytics, no server-side copy of anything. Data lives on devices you control and moves between them only when you tell it to. Four approaches make this work for curated YouTube subscriptions, from a manual export you can finish in minutes to peer-to-peer replication that runs itself, plus a decision flow for choosing between them and recovery steps for the day two devices edit the same file.
Chrome extension storage limits: why chrome.storage.sync fails the no-account test
The obvious answer for a Chrome extension is Chrome's built-in sync storage, chrome.storage.sync. Two constraints decide whether it can do this job: what it requires and how much it lets you store.
First, the account requirement. Chrome's storage documentation states that with syncing enabled, "the data syncs with every Chrome browser that the user is logged into." A signed-in Google account with sync turned on is mandatory. When sync is disabled or the browser is offline, sync storage behaves like local storage and queues changes until reconnection, so there is no account-free mode hiding underneath.
Second, the size. chrome.storage.sync does not offer open-ended storage: it enforces byte quotas on the total an extension can keep and on each stored item, with separate ceilings on how often data can be written. When a limit is breached, chrome.storage.sync.set() rejects with an error message containing the limit name, and the browser does not retry automatically, so working code needs explicit error classification, chunking, and backoff.
A curated set of channel lists can fit inside those limits without much effort. A watched-state history does not, because it grows by one entry per marked upload and updates constantly, exactly the pattern the write caps punish. That is why chrome.storage.local is the better baseline: about 10 MB by default in current Chrome, raised from 5 MB, and expandable with the unlimitedStorage permission. File-based sync of an export taken from local storage beats fighting chrome.storage.sync for any library that keeps history.
Manual export and import: the privacy-first baseline
This workflow needs no account and no infrastructure: export your subscription list on one device, import it on the others.
Google's official path is Takeout, which produces a subscriptions.csv file. It works, but it is heavy. One practitioner exporting 500-plus subscriptions avoided a second request because dumps "take a long time to generate and also result in multiple gigabytes of archives" just to reach that single CSV.
There is a lighter route. Google publishes an RSS feed for every channel, youtube.com/feeds/videos.xml?channel_id=..., with no YouTube Data API key required. Converting the channel list into a standard OPML bundle makes it importable by any RSS reader on any device, which makes OPML a fully account-optional export format.
The workflow is one line: export on the source device, import on every target device. Be honest about the trade-off, because this is snapshot sync. Changes made between exports stay on the machine where you made them, whether that is a channel added on the laptop or a list renamed on the phone, until you export again. The same export doubles as a backup worth having even if you never sync.
File-based sync with Syncthing, peer to peer
Syncthing replicates a folder between your own machines with no third party in the middle. Its FAQ puts the principle plainly: "Syncthing does not upload your data to the cloud but exchanges your data across your machines as soon as they are online at the same time." Creation, modification, and deletion on one device replicate directly to the others.
Connecting two devices requires accepting the pairing on both sides, which the same FAQ frames as a deliberate security-over-convenience choice against stolen credentials. The friction is small and the protection is real: a leaked device identity cannot silently attach a new machine to your folder.
One caveat shapes how an extension consumes a synced folder. Under Manifest V3, extensions cannot passively watch a folder in the background. Realistic setups therefore sync the export file and use an explicit import step on each device, or add a small native-messaging helper that loads changes into extension storage automatically.
Best fit: two or more of your own machines, with replication and nothing uploaded to the cloud.
Self-hosted WebDAV: the middle ground
If you already run a NAS or a self-hosted Nextcloud or ownCloud instance, a WebDAV endpoint gives every device a single canonical copy of the export file. This still counts as no third-party cloud account, because the server belongs to you. Tools like rclone can front a NAS so your extension sees one plain WebDAV endpoint.
The same limitation applies as with Syncthing, no passive background folder watching, so plan for explicit imports or a native-messaging helper here too.
Best fit: existing home infrastructure, and a preference for one authoritative copy over peer-to-peer replication.
Yougroup's export-and-sync pattern
Yougroup is a working example of this pattern. It is an open-source Chrome extension for organizing YouTube subscriptions into curated lists, and it is local-first in the strict sense: no Yougroup account, no hosted backend, no server-side sync, and no product analytics. Everything lives in Chrome extension storage.
You group channels into themed lists such as research, recipes, or interviews, and those lists feed a deduplicated, cross-list feed of new uploads. The extension reads YouTube RSS feeds with no API key required; an API key is optional for richer details such as duration and view counts. Watched marks and playback queues, sortable by newest, popular, or interleaved, stay local. The export pattern pairs with any workflow above: export on one machine, move the file by hand, through Syncthing, or over WebDAV, then import on the next.
Developers can clone the source, build it, and load the unpacked extension in Chrome 114+ to adapt the pattern for their own tools. If you are comparing organizers rather than building one, checking export formats first prevents lock-in before it starts, and clearly structured lists travel better between devices than ad-hoc ones.
Decision flow: picking your sync path
Route yourself from simplest to most automated:
- One device, occasional moves: manual export and import of an OPML bundle or an extension export. Fully account-optional, nothing to maintain.
- Two or more of your own devices, automatic replication: Syncthing peer-to-peer folder sync.
- You already run a NAS or Nextcloud: self-hosted WebDAV, with
host_permissionsdeclared. - You are a developer tempted by
chrome.storage.sync: workable only for small, slowly changing data that fits its quotas, and only for users who accept signing into a Google account.
The rule of thumb from all of this: channel lists are small, watched-state histories grow. Match the sync method to the payload before you match it to the convenience.
When sync conflicts strike: .sync-conflict files and recovery
Automatic replication eventually means two devices edit the same export file at once. Syncthing's documented behavior: when a file is modified on two devices with differing content, one copy is renamed to a .sync-conflict file. The version with the older modification time is marked conflicting, and if timestamps tie, the copy from the device whose ID has the larger value in its first 63 bits loses. The conflict file is then treated as a normal file and propagates to every device.
That last detail is the quiet problem. Syncthing core ships no conflict-merge tool and no conflict-detection UI; it picks a winner, renames the loser, and waits for you to notice. One user auditing roughly 50,000 synced files found 27 conflicts they had never seen. The Windows wrapper SyncTrayzor is the notable exception, adding a simple GUI resolver on top of the otherwise conflict-silent web interface.
Recovery is a deliberate merge, not an automatic one:
- Stop editing on every other device.
- Diff the canonical file against the
.sync-conflictcopy. - Merge the changes into one file by hand.
- Delete the loser.
Ownership over convenience
Syncing curated YouTube lists without a cloud account is entirely achievable once the method matches the payload and the devices involved. Manual export wins on simplicity, Syncthing on automation, WebDAV for self-hosters who want one authoritative copy, and chrome.storage.sync only with eyes open to its quotas and its Google-account requirement. What you give up is a little convenience. What you keep is ownership, privacy, and a setup you can inspect end to end.
Try Yougroup's local-first approach to curated YouTube lists, or clone the open-source code and adapt its export-and-sync pattern for your own workflow.