A desktop AI assistant organizes browser history into categorized bookmarks locally, beside a sleeping cat and coffee mug.
XDA Developers writer Anurag Singh fed two weeks of Chrome browsing history to a local language model. He asked it to build a bookmark system. The result was 75 bookmarks in organized folders, plus a spreadsheet explaining each pick. It is a neat little experiment in local AI and browser data handling. It also shows where such a workflow is useful and where it needs care. The test ran on a Mac, but the approach carries over to Windows with a few changes.

A desktop AI assistant organizes browser history into categorized bookmarks locally, beside a sleeping cat and coffee mug. What the experiment actually did​

Singh's setup was simple. He used LM Studio running Qwen3.5 9B. His history covered two weeks of browsing, which the original report puts at 4,617 visits across 1,401 URLs. Those counts include repeat visits, so they don't mean 4,617 distinct pages.

He asked the model to do three things:

  • Pick out links worth keeping, especially pages he kept returning to and reference material.
  • Sort them into folders.
  • Produce an HTML file he could import into Chrome, along with a CSV giving the reason for each selection.

The folders included a "Daily launchpad" of 11 destinations. These were an analytics dashboard, Asana task lists, Slack channels and shortcuts for creating a new article or Google Doc. A technical reference folder gathered documentation, installation guides, GitHub repositories and NAS backup resources.

The standout finding was about habit. Singh says he visits r/selfhosted and r/opensource almost daily, but always by opening Reddit and searching. The model flagged them as top destinations, and he had never thought to bookmark them.

These numbers and outcomes are Singh's own account. They aren't independently verified. He also says he wanted to change a few of the model's decisions. Treat the output as a draft for a human to review, not a finished classification.

How to get your history out of Chrome​

Singh's method is to find the profile folder and copy the History file elsewhere. Chromium's documentation confirms the first step. Open chrome://version and look at the Profile Path field. That path points to your profile directory. Chromium says the user data directory is its parent, and that profile data such as history and bookmarks lives there.

Default user-data locations, per Chromium's documentation:

PlatformDefault Chrome location
Windows%LOCALAPPDATA%\Google\Chrome\User Data
macOS~/Library/Application Support/Google/Chrome
Linux~/.config/google-chrome

Each profile is a subfolder, often named Default. Singh quit Chrome before copying the History file, which avoids grabbing a file that is in use. He worked on the copy and left the original alone. That is sensible practice on any OS.

The source doesn't say how he turned the history file into something the model could read. It doesn't give his prompt, his model settings or the generated files either. Anyone repeating this will need to work out that middle step themselves. That might mean exporting titles, URLs and visit counts to a text or CSV file, since the model needs those fields, not the raw database.

Importing the result​

Chrome can import a bookmarks HTML file. Google's help page says to open Chrome and choose More, then Bookmarks and lists, then Import bookmarks and settings. Then select Choose file, pick the file, and select Open and Done.

Where the bookmarks land depends on your profile. One third-party guide, TrueBookmark, says an empty bookmarks bar receives them directly. Otherwise they go into a folder under Other bookmarks, and existing bookmarks aren't changed. The same guide says Chrome doesn't check for duplicates, so back up your current bookmarks before importing. That is vendor-blog guidance rather than Google documentation, but it's a cheap precaution.

Why "local" matters here, and where it stops​

Browser history is revealing. It shows work documents, searches, interests and the services you use. Singh says he didn't want to hand all that to a large tech company just to get some folders tidied. That is a fair instinct.

LM Studio's privacy policy backs up the core claim. If you download and run models locally, the policy says your messages, chat histories and documents are never transmitted from your system. There are caveats:

  • The app does communicate when you search for or download models.
  • It also communicates when it checks for software updates.
  • Cloud models and web search are separate features. If you use them, your requests are processed in the cloud, which the policy says is done transiently under zero-data-retention terms.

So "local" describes where inference happens. It doesn't guarantee that nothing around the app touches the network. If you try this, use a model that is downloaded and running on your machine, and leave cloud features off.

Limits worth knowing​

Singh is candid about the weak points, and they matter:

  • History is thin context. Titles and URLs don't include page text, so the model is guessing at importance.
  • Frequency isn't value. A page opened many times during a one-off project can look essential and then become clutter.
  • Sensitive and personal sites. The history mixes work and personal browsing. Review the selected list before importing, and strip anything you don't want sitting in a bookmark bar.
  • Staleness. The model can only reflect the last two weeks. That is a strength for finding current habits and a weakness for anything seasonal.

The CSV rationale is the most useful design choice. It gives you a reason for each link, so you can audit the list instead of trusting it blindly.

The monthly automation is only a plan​

Singh says he plans to build an n8n workflow that sends his history to the local model every month and rebuilds the bookmark set. He describes it as a work in progress and promises an update. No workflow, schedule or results have been published, so it is an idea, not a demonstrated capability.

If you build something similar, think about a few questions first:

  1. How will history be filtered before it reaches the model?
  2. Will a human review step stay in the loop?
  3. How will new imports avoid duplicating or overwriting existing bookmarks?
  4. Is the model's local server reachable only from your own machine? LM Studio's documentation recommends authentication if you expose the server to other devices on your network.

Bottom line​

This is a practical, low-risk use of a small local model. It takes data you already have, produces a file you can inspect, and keeps the human in charge of what gets imported. The results come from one writer's two weeks of browsing, so don't expect identical numbers. The method itself is sound: find your profile, copy the history, let a local model draft the list, review the CSV, then import. Windows users can follow the same steps. The main changes are the profile path under %LOCALAPPDATA% and the Ctrl+Shift+O shortcut for the bookmark manager.

 

References

  1. I gave my local LLM my browser history, and it built a better bookmark system than I ever had XDA 2026-10-27T13:01:22+00:00
  2. Export your data from Chrome - Google Chrome Help support.google.com
  3. Chromium Docs - User Data Directory chromium.googlesource.com