Cluster — Save Browser Tabs as Sessions, Not Bookmarks

A Chrome Extension (Manifest V3) that lets you save a group of tabs together as one named, searchable "cluster" — so you can close 10–30 tabs with confidence and resume the exact same session later in one click.

---

The Problem

People keep 10–30 tabs open during active work because closing them feels risky — there's no guarantee they'll remember why a tab mattered or be able to find it again. Native browser bookmarks only store a URL + title: no context, no grouping, no sense of why something was saved. Bookmark lists grow long, unstructured, and eventually unsearchable, so users stop bookmarking altogether and just... never close anything.

The Solution

Cluster lets you select any number of currently open tabs, name them as a group, add an optional description and category, and save the whole thing as one unit. Resuming reopens every tab in that group together, in a new window — picking your work back up exactly where you left it.

---

Features

• Multi-tab selection — pick any combination of open tabs in the current window, not just the active one
• Save & Close — optionally close only the tabs you just saved; everything else stays open
• Categories — tag clusters (Work, Research, Shopping, Learning, Personal, Travel, Other) for fast filtering
• Timeline dashboard — clusters grouped into Today / Yesterday / specific dates, newest first
• One-click Resume — reopens every tab in a cluster together in a fresh window
• Full editing — rename, re-describe, re-categorize, remove tabs, or add currently-open tabs to an existing cluster
• Search — across cluster name, description, category, and every saved tab's title/URL
• 100% local — no account, no backend, no network calls, no data leaves the browser

---

Tech Stack

Layer	Technology	Why
Extension platform	Chrome Extension Manifest V3	Current required architecture for Chrome Web Store distribution
Languages	JavaScript (ES6+ Modules), HTML5, CSS3	No build step needed at this scope; MV3's CSP blocks remote framework bundles in extension pages anyway, so plain JS avoids that friction entirely
Storage	chrome.storage.local	Built-in, sandboxed, async key-value store — appropriate for personal, local-only data with no need for a backend
Browser APIs	chrome.tabs, chrome.windows, chrome.runtime	Querying open tabs, reopening tab groups in new windows, and page-to-page messaging
Background	Service Worker (lib/background.js)	MV3's event-driven replacement for the old always-on background page

---

Installation

Since Cluster is not yet available on the Chrome Web Store, you can install it manually.

1. Download

Download the latest release from the Releases page.

2. Extract

Extract the downloaded ZIP file.

3. Open Chrome Extensions

Visit:

chrome://extensions/

4. Enable Developer Mode

Turn on Developer Mode in the top-right corner.

5. Load the Extension

Click Load unpacked.

Select the extracted extension folder.

Done!

Cluster should now appear in your browser toolbar.

---

Project Structure

.
├── manifest.json           # Extension config — permissions, icons, entry points
├── popup.html / popup.js    # Click-the-icon UI: tab picker + save form
├── dashboard.html / .js     # Full-page UI: cluster cards, search, filters, edit modal
├── lib/
│   ├── storage.js           # Data layer — all chrome.storage.local CRUD operations
│   ├── background.js        # Service worker (MV3 requirement)
│   └── styles.css           # Shared design system (single accent color, consistent spacing)
├── icons/                   # Extension icon, 16/48/128px
├── screenshots/             # README images
└── README.md

---

Architecture Notes

Why no database / backend? All data is personal and local to one browser. chrome.storage.local is purpose-built for exactly this: instant, sandboxed, per-extension key-value storage with no network round-trip and no privacy exposure. Introducing a server here would add cost, latency, and risk for zero functional benefit.

Why no React/frontend framework? Two reasons. First, scope: a few hundred lines per file with simple, page-local state doesn't need a component framework's overhead. Second, a Manifest V3-specific constraint: extension pages enforce a strict default Content Security Policy that blocks loading remote scripts — so a CDN-based React setup won't run at all, and a proper build would require a bundler (Vite/Webpack) just to produce a static bundle. Plain ES modules sidestep that friction entirely while keeping the same separation of concerns (storage.js as an isolated data layer, completely decoupled from the UI files) that would make a future migration straightforward if ever needed.

How saving actually works, end to end:

1. popup.js calls chrome.tabs.query({ currentWindow: true }) to list every open tab.
2. User selects tabs, names the cluster, picks a category.
3. storage.js's saveCluster() builds a record — { id, name, description, category, tabs[], tabCount, savedAt } — and writes it into the existing array in chrome.storage.local.
4. dashboard.js reads that array back, sorts by savedAt descending, and renders it grouped into timeline buckets.
5. Resume takes the cluster's stored tab URLs and calls chrome.windows.create({ url: [...] }), reopening the whole session in one new window.