I Built a Chrome Extension That Finally Makes Bookmarks Searchable — Here's How

Jagadeesh Jayachandran — Fri, 06 Mar 2026 17:01:46 +0000

The Problem Nobody Talks About

You know that feeling. You saved a link weeks ago — a brilliant tutorial, a useful tool, a must-read article. Now you need it. You type something vague into your bookmarks search bar... and get nothing.

So you open your bookmarks manager and start clicking through folders named "Useful", "Dev Stuff", "Read Later", and "Misc". Twenty minutes later, you give up and just Google it again.

I had this problem every single day. And after years of dealing with it, I decided to build a proper solution.

That's how Recall: Smart Bookmark Search was born.

What Is Recall?

Recall is a Chrome extension that transforms your bookmark library from a cluttered folder system into an intelligent, searchable knowledge base. Instead of remembering exact titles or folder paths, you can search like a human:

"that webpack config article"
"React tutorial from last week"
"design tools from the CSS conference"

And it actually finds them.

Chrome Web Store: Install Recall

The Technical Foundation

1. Content Indexing — Going Beyond the Title

The biggest insight was this: the page title is almost never what you remember. You remember what the page was about.

So when you save a bookmark, Recall injects a content extractor script that scrapes:

Page title and URL
Meta description and keywords
H1, H2, H3 headings
Main body paragraphs
Image alt text
Link titles

It then extracts the top 50 keywords by frequency, weighted by their position in the document. This becomes your searchable index.

// Simplified keyword extraction
function extractKeywords(content) {
  const words = tokenize(content);
  const frequency = {};
  for (const word of words) {
    if (!isStopWord(word)) {
      frequency[word] = (frequency[word] || 0) + 1;
    }
  }
  return Object.entries(frequency)
    .sort((a, b) => b[1] - a[1])
    .slice(0, 50)
    .map(([word]) => word);
}

2. Fuzzy Search with Levenshtein Distance

Exact string matching is useless when you can't remember the exact title. Real search needs to tolerate typos and partial matches.

I implemented fuzzy matching using the Levenshtein distance algorithm — so "devinci" still matches "DaVinci", and "recat" still finds "React".

3. Smart Relevance Scoring

Not all matches are equal. Recall scores results across multiple signals:

Signal	Points
Tag match	+25
Phrase in title	+20
Title keyword match	+20
Description match	+12
URL keyword	+15
Content keyword	+10
Saved recently (<7 days)	+5

This means if you tagged something "css-tricks", it bubbles to the top immediately.

4. Auto-Categorization

Nobody wants to manually categorize every bookmark. Recall uses URL pattern matching and content keyword analysis to auto-assign one of 12 categories:

Development, Education, Entertainment, Productivity, Finance, Health, Design, Food, Travel, News, Books, Other

// Example category detection
if (url.includes('github.com') || url.includes('stackoverflow.com')) {
  return 'Development';
}
if (url.includes('coursera.org') || url.includes('udemy.com')) {
  return 'Education';
}

Features That Make It Practical

Visual Snapshots

When you save a bookmark, Recall automatically captures a screenshot of the page. This is surprisingly useful — you often recognize a page visually before you remember its title.

Reading List

Shift+Click the save button to add anything to your reading queue. Your dashboard shows the top 3 items at all times, so nothing gets buried.

Duplicate Detection

Uses URL normalization (strips UTM params, tracking tokens) plus Jaccard similarity on titles with an 80% threshold. It catches duplicates even when URLs are slightly different.

Dead Link Validation

Batch HTTP status checking with Archive.org fallback for 404s. Dead links get marked with a warning badge so you can clean up your library.

Challenges I Solved

Storage limits: Chrome extensions have a 10MB default storage quota. For large bookmark collections with screenshots, this fills up fast. I switched to chrome.storage.local with unlimitedStorage permission and added base64 compression for snapshots.

Manifest V3 restrictions: Background service workers in MV3 are ephemeral — they spin down when idle. I had to carefully architect the indexing pipeline to handle interrupted jobs gracefully.

Search speed: With 1,000+ bookmarks, naive search was too slow. Pre-building keyword indexes at save time (rather than search time) brought results down to under 300ms.

What's Next

Semantic search using local embeddings (no server required)
Firefox support
Sync across devices (opt-in, encrypted)
Browser history integration

Try It

If you're drowning in bookmarks, give Recall a try. It's free, requires no account, and keeps everything 100% on your device.

👉 Install on Chrome Web Store

I'd love to hear what features you'd want next — drop them in the comments below!

Stop Writing Brittle Tests: The Smart Locator Strategy Every Playwright Dev Needs

Jagadeesh Jayachandran — Wed, 18 Feb 2026 22:18:47 +0000

I spent hours debugging a flaky test that broke because of one line of XPath.

The fix? A single Playwright locator that took 10 seconds to write.

Here's what I wish I knew earlier.

The Hard Truth

If your tests are flaky, your locators are the problem.

Traditional XPath and CSS selectors navigate the DOM like a tree. The moment a developer reorders elements or changes structure — your tests break. Every. Single. Time.

// Brittle - breaks if DOM structure changes
page.locator('div#main > ul:nth-child(2) > li:first-child > button')

Human Vision vs Robot Vision

Playwright takes a completely different approach. Instead of hunting for IDs and class names (robot vision), it targets elements the way a real user would — by what they see on screen (human vision).

The gold standard? page.getByRole()

It taps into the accessibility tree — the same structure screen readers use. If a screen reader can find it, Playwright can test it. And it survives refactors.

// Smart - survives DOM changes
page.getByRole('button', { name: 'Sign up' })

The Locator Priority Hierarchy

Follow this order and you'll solve 80% of your locator problems:

1. getByRole — Always start here. Works for buttons, headings, checkboxes, links, and more.

2. getByText / getByLabel — Fall back to visible on-screen text or form labels.

3. getByTestId — Ask your dev to add a data-testid attribute. It's stable and won't change by accident.

4. CSS/XPath — Last resort only. Even then, paste it into an LLM — it'll convert it to a getByRole locator for you.

Bonus: No More sleep() Hacks

Playwright's built-in auto-wait means every locator automatically waits for the element to be attached, visible, stable, and enabled before acting. No more arbitrary timeouts.


js
// You no longer need this
await page.waitForTimeout(3000)

In this code snippet, the playwright library is being used to automatically handle clicking on a button element with the role of 'button' and the name 'Submit'. The code is locating the button using the getByRole query function and then triggering a click event on it using the click() method. This allows for automated interaction with the webpage in order to submit a form or perform some other action.y {
  const submitButton = await page.getByRole('button', { name: 'Submit' });
  await submitButton.click();
} catch(err) {
  console.error("Error clicking submit button: ", err);
}
This is Part 2 of my Playwright 80/20 Pareto Principle series. Part 3 covers Playwright Actions — coming soon!

🎬 Watch the full video here: https://www.youtube.com/watch?v=6IaCQ70cNVc

Forem: Jagadeesh Jayachandran