A library you actually use.

A collection is a folder for saved items. The same item can belong to many. The same collection can hold items of different kinds — articles next to videos next to podcasts. The structure exists for one reason: so that a year from now, when you can’t remember the title but you remember why you saved it, you can still find it.

How they behave

Three properties to keep in mind.

— Membership is a set, not a path. An item is in a collection or it isn’t. Removing it from one collection doesn’t remove it from the others. An article you saved into Reading and Long-form and 2026 sits in all three; clearing Reading leaves it in Long-form and 2026.

— The root is implicit. Saves land in your library without a default collection. Items not assigned to any explicit collection still appear in the popup under All.

— Renaming a collection doesn’t break links. Collections are stored by ID, not by name. Rename freely.

Nesting

Free readers can nest collections one level deep: Reading → Long-form, but not Reading → Long-form → 2026. Pro readers can nest up to five levels.

The depth limit exists because, past a point, a deeper folder tree is worse at retrieval than a flatter one with more tags. Five is a generous ceiling — most readers settle on two or three.

In the popup, the chip row is a single-level slice of the tree. Tap a collection chip and the popup drills down to that collection; a ← back arrow appears in the breadcrumb pill to step up one level. The breadcrumb in the popup header tells you where you are.

How to assign a collection on save

There are two ways. The first is per-item, after a save lands: open the popup, find the item, and use the Add to collection picker on its row. You can add the same item to several collections this way.

The second is automated, and it’s the Smart Rules feature below. A rule with an addToCollection action will drop every matching save into the collection you pick — youtube.com into Watch later, kind = podcast into Audio, and so on. The rule fires the moment the save lands.

Smart Rules (Pro)

Smart Rules are a Pro-only feature. A Smart Rule is a condition → action that runs the moment a save lands in the library. If the hostname contains youtube.com, add it to Watch later. If the title contains “review”, add the tag reviews. If the kind equals podcast, add it to Audio.

Where to set them up

Open the Options page and scroll to the Step six · Smart Rules card, between Step five · AI · Pro and Step seven · Library tools. The card shows the existing rules and a + New rule button that opens a fresh editor.

Each rule has a name (free text, up to eighty characters), a conditions block, a conditions logic toggle (match all / match any), and an actions block. Edits live in a draft until you click Save (or Cancel to discard).

Conditions

A condition picks a field and an operator and matches against a value (lowercased on both sides, trimmed).

Field	Tests against
hostname	nytimes.com, youtube.com, arxiv.org
url	the full URL including path and query
title	the document.title captured at save time
kind	one of article, video, podcast, page

Operator	Match
equals	exact match (case-insensitive)
contains	substring match
startsWith	prefix match
endsWith	suffix match

A rule with multiple conditions is evaluated under its logic setting. Match all requires every condition to be true (AND). Match any requires at least one (OR). Rules with no conditions never match — the form keeps them disabled until you add at least one.

Actions

Two actions, both additive:

— addTag — adds a tag to the saved item. Existing tags are not removed. If the tag is already present (case-insensitive), the action is a no-op. — addToCollection — adds the item to the named collection. Membership is a set, so applying the same rule twice does nothing the second time.

Rules cannot remove tags, move items between collections, send notifications, fetch external data, or modify items other than the one that triggered the rule. The restriction is intentional — Smart Rules are post-save annotation, not a workflow engine.

Ordering and enabling

Rules are evaluated top-to-bottom in the order they appear in the list, but multiple matching rules all apply — union semantics on tags and collection memberships. The first match does not exclude the others, so order rarely matters in practice; what changes is only which mutation happens first.

A rule can be disabled with the toggle on its row — useful when you want to keep the definition but stop it from firing.

When they fire

Rules run post-save, asynchronously, in the background service worker. The capture flow does not wait for them; if a rule fails (a collection was deleted, an addTag action carries an empty value), the failure is logged and the save itself is unaffected.

Rules only act on new saves. Importing from Pocket does not re-run rules over the imported items, and editing an item later does not re-evaluate the rules against it. To apply a new rule to an existing library, run the bulk action by hand from the Step seven · Library tools card.

Scope

Rules are scoped to this device — they live in chrome.storage.local alongside the library. They are not synced. To replicate a setup on another machine, recreate the rules there.

Notion routing

Notion routing falls out of the collection action: if a rule adds the item to a collection that has a Notion database mapping, the export will use that database. See Pro features → Multi-database Notion routing.

A note on tags vs. collections

If the question “tag or collection?” comes up, here’s the working answer: collections are for retrieval, tags are for filtering. A collection is a destination the item will live in. A tag is a property the item carries. Collections nest; tags don’t.

That said: nothing forces this distinction. Shelf doesn’t penalise overlap. If you find yourself making a tag and a collection with the same name, pick whichever feels lighter and stop second-guessing.