I Built a Privacy-First Screenshot Organizer Using IndexedDB — Here's What I Learned

Adnan Khan — Tue, 02 Jun 2026 17:32:12 +0000

After about a year of building, I shipped Captop — a screenshot organization tool that stores screenshot data client-side using IndexedDB. Screenshots never leave your device; auth and billing metadata go through Supabase, but your actual captures stay local. No cloud uploads of screenshot data, no account required for the core experience.

I want to write about the technical decisions, because some of them were non-obvious and a few of them I'd make differently now.

Why IndexedDB

The privacy constraint came first: screenshots had to stay on the device. No server ever seeing your screenshot images. That ruled out the obvious approaches (Supabase, Firebase, any traditional backend) for the screenshot storage layer. Auth and billing use Supabase — that's unavoidable for a paid product — but the actual image data never touches it.

The options for genuinely local storage in a browser-based app are limited:

localStorage — synchronous, 5MB limit, not appropriate for binary data
Cache API — designed for caching network requests, technically usable but semantically wrong
File System Access API — powerful and increasingly well-supported, but requires explicit user permission on every origin and has awkward Safari support
IndexedDB — asynchronous, stores structured data and blobs, no meaningful size limit in modern browsers, works offline, available everywhere

IndexedDB won by default, but it's also genuinely the right tool. It's fast enough for the workload (we're not doing analytics queries, we're doing key-value lookups and light filtering), it handles large binary blobs for image storage without converting to base64, and it's durable — data survives browser restarts, memory pressure, and service worker updates.

The API, however, is famously verbose and callback-based. Nobody writes raw IndexedDB in production code.

The Storage Abstraction

I wrote a thin wrapper around IndexedDB that gives the rest of the app a clean async interface. The core of it looks roughly like this:

class CaptopDB {
  private db: IDBDatabase | null = null;

  async open(): Promise<void> {
    return new Promise((resolve, reject) => {
      const request = indexedDB.open('captop-db', CURRENT_VERSION);

      request.onupgradeneeded = (event) => {
        const db = (event.target as IDBOpenDBRequest).result;
        this.runMigrations(db, event.oldVersion);
      };

      request.onsuccess = () => {
        this.db = request.result;
        resolve();
      };

      request.onerror = () => reject(request.error);
    });
  }

  async getScreenshot(id: string): Promise<Screenshot | null> {
    return this.transaction('screenshots', 'readonly', (store) =>
      store.get(id)
    );
  }

  async putScreenshot(screenshot: Screenshot): Promise<void> {
    return this.transaction('screenshots', 'readwrite', (store) =>
      store.put(screenshot)
    );
  }

  private async transaction<T>(
    storeName: string,
    mode: IDBTransactionMode,
    operation: (store: IDBObjectStore) => IDBRequest<T>
  ): Promise<T> {
    return new Promise((resolve, reject) => {
      const tx = this.db!.transaction(storeName, mode);
      const store = tx.objectStore(storeName);
      const request = operation(store);
      request.onsuccess = () => resolve(request.result);
      request.onerror = () => reject(request.error);
    });
  }
}

The object stores: screenshots, folders, workbooks, tags, notes, settings. Each screenshot record stores the image data as a Blob (not base64 — blobs are significantly more memory-efficient in IndexedDB and faster to read).

Schema Design and Versioning

One of the things IndexedDB gets right: it has a versioning mechanism built in. When you bump the version number on indexedDB.open(), the onupgradeneeded event fires with the old and new version numbers, and you run whatever migrations you need.

I learned to be conservative with schema changes. You can add new object stores and indexes easily. Deleting or renaming them requires more ceremony. Migrating data between schemas requires reading from the old store, transforming, writing to the new one — all inside the upgrade transaction, before the database opens.

The migration runner I ended up with is simple:

function runMigrations(db: IDBDatabase, fromVersion: number): void {
  const migrations: Record<number, (db: IDBDatabase) => void> = {
    1: createInitialSchema,
    2: addTagsAndNotesStores,
    3: addWorkbookIndex,
    4: addSearchMetadataStore,
  };

  for (let v = fromVersion + 1; v <= CURRENT_VERSION; v++) {
    migrations[v]?.(db);
  }
}

Each migration function creates or modifies object stores and indexes. Running them sequentially means a user upgrading from v1 to v4 in one jump runs all intermediate migrations correctly.

The Chrome Extension

The extension is Manifest V3. The architecture:

Service worker (background) — handles extension lifecycle, message routing, context menu registration
Content script — injected into pages, handles region selection overlay, stitches full-page captures, communicates with the service worker
Popup — unified capture UI: choose area capture or full-page capture, pick destination workbook/folder, assign hotkey presets

The tricky part: the extension needs to communicate with the web app (captop.in) to save screenshots to the IndexedDB that lives in the web app's origin. This is a genuine constraint of how browser storage works — IndexedDB is scoped to an origin, so the extension can't directly write to the web app's database.

The solution is cross-origin messaging with explicit user consent. The extension sends a message to the web app via window.postMessage, the web app validates the message origin and content, and handles the save. The extension's content script injects a small bridge into pages that are already on captop.in, and uses a background service worker to coordinate.

This means the web app needs to be open (in any tab) for the extension to save directly. In practice, users either have it open or the extension queues captures in chrome.storage.local and the web app drains the queue when it next loads. It's a tradeoff I made to avoid any server involvement — the only alternative would be a relay server, which defeats the privacy goal.

Search

Full-text search is entirely client-side, running over the notes and tag metadata attached to screenshots. I'm using a simple inverted index built at startup from all screenshot metadata.

I did implement OCR text extraction, and the privacy model holds. Tesseract.js runs the extraction entirely in the browser — no image is sent anywhere. When you save a screenshot, the OCR job kicks off asynchronously in the background and the extracted text surfaces in the view panel when it's ready. It doesn't yet feed into the main search index (that's a known limitation I'm actively working on), but the extraction itself is local. The current search contract covers notes, tags, and workbook/folder names. That's already enough to find most things well, because even a single descriptive note dramatically changes retrieval. OCR will make it better for screenshots where you didn't add a note.

What I'd do differently

Earlier user testing. I was building in isolation for too long. Some decisions I thought were clever turned out to be confusing to actual users, and I only found out after shipping.

Reconsider File System Access API. The storage situation was less mature when I started. Today I'd look harder at OPFS (Origin Private File System) for the main storage layer — it's faster for large binary data and the browser support story is better than it was a year ago.

Leaning harder on PWA earlier. The web app + extension covers the vast majority of real use cases. I'd have invested more in the PWA experience sooner.

The product itself

Captop is live at captop.in. Free tier: 100 screenshots, all features, no card required. Paid plans start at $30/year.

Chrome extension on the Web Store. The codebase is React + TypeScript + Vite. The key architectural decision: screenshot data lives in IndexedDB on-device, not in any cloud database. Auth and billing run through Supabase, but your captures and notes never leave your machine.

If you have questions about the IndexedDB architecture, the extension messaging model, or any of the decisions above — happy to discuss in the comments.

→ captop.in

DEV Community: Adnan Khan