Browser Memory: sessions, not just a list of URLs

The first time I seriously looked at Chrome's history page as a product builder, I realized something simple:

It remembers the wrong unit.

Chrome remembers visits. I remember sessions.

A visit is one page. A session is the reason that page existed in the first place.

That difference is why normal browser history often feels so frustrating. It has the data, but it does not preserve the shape of the work. It can tell me that I opened a docs page at 8:24 PM. It can tell me I visited GitHub, MDN, Stack Overflow, Wikipedia, Hacker News, and an npm package. But it does not tell me the more useful thing:

"You were working through one research burst. Here are the pages that belonged together."

That is the idea behind Browser Memory.

Not just a list of URLs.

Sessions.

A URL is not the same as context

When I lose a page, I usually do not lose it because the browser failed to save it.

I lose it because I cannot remember how to describe it.

Maybe I remember the task: I was comparing libraries. I was debugging storage. I was reading browser extension docs. I was looking for examples of a settings page. But Chrome history does not start from the task. It starts from the URL.

That puts the burden back on me.

I have to remember the domain, the title, the day, or the exact search phrase. If I do not, I end up scanning rows like I am reading a receipt from a store I barely remember visiting.

That is why I wanted Browser Memory to treat sessions as first-class objects.

A session is closer to how the brain works. It says, "these pages happened together." It keeps the surrounding context intact. Even if one page title is vague, the pages around it can help me understand what I was doing.

That surrounding context is often the memory.

How a session starts to feel different

Imagine two versions of the same history.

In the first version, you see this:

• IndexedDB API page
• React package page
• Stack Overflow question
• GitHub issue
• MDN reference
• Chrome extension docs

That is useful, but only if you already know what you are looking for.

In the second version, those same pages are grouped as a single session. Now the browser is saying:

"This was one development research block. You opened these pages together. You can return to the whole set."

That is immediately more useful.

The pages stop being scattered debris and start becoming a trail.

This is especially helpful for the kind of browsing that happens when you are building, designing, comparing, learning, or debugging. Those tasks almost never happen on one page. They happen across clusters of pages.

A history tool that ignores the cluster is always going to feel a little broken.

Why I used inactivity gaps

Browser Memory groups sessions using inactivity gaps.

That means it watches the natural rhythm of browsing. If I am active for a while, those pages can belong together. If I stop for long enough, the next activity becomes a different session.

This is not magic, and that is the point.

I did not want session grouping to feel mysterious. I wanted it to be explainable. If a group looks wrong, the rule should be understandable enough that I can tune it later.

There is something honest about a simple rule that works most of the time.

It does not pretend to know my intention perfectly. It simply notices that browsing tends to happen in bursts, and it gives those bursts a container.

That container is enough to make history dramatically easier to revisit.

The title is a hint, not a prophecy

One thing I had to be careful with was session naming.

A bad session title can be worse than no title if it acts too confident. I did not want Browser Memory to invent dramatic summaries of my day. I just wanted helpful labels.

So the titles are deterministic. They come from local rules, domains, page titles, and category patterns. A session might get a title like "Development Research" or "Shopping Research" because the pages inside it point in that direction.

The title is a hint.

It gives the session a handle, but the real value is still the pages inside the group.

That is a healthy level of intelligence for this kind of product. Helpful, but not theatrical.

Sessions make search better too

Search is useful in any history tool, but sessions make search more powerful.

If I search for a word and find one page, I often want the pages around it. The exact result may not be the thing I need. It may only be the doorway back into the task.

That is why a session-based history page can feel different from a normal search result list.

A match can lead me back to the full browsing context. I can see what came before, what came after, what other domains were involved, and whether I saved notes or favorites around that work.

That is how people actually recover information.

We rarely remember everything cleanly. We remember one clue, then rebuild the path from there.

Sessions help with that rebuilding.

The timeline still matters

Sessions are not the only way to remember browsing.

Sometimes I remember the date. Sometimes I know I was working on something yesterday or last Friday. In that case, a timeline view is the right tool.

That is why Browser Memory has both.

The timeline is for chronological memory. Sessions are for task memory. Domains are for source memory. Collections are for intentional memory. Notes are for personal memory.

Those are different paths back into the same history.

I wanted Browser Memory to support more than one kind of remembering because my own memory is not consistent. Some days I remember the site. Some days I remember the task. Some days I only remember that I was working late and opened something useful.

A good history replacement should meet me from any of those directions.

Why this matters for people who keep too many tabs open

I think a lot of tab hoarding is really fear.

Not fear in a dramatic way. Just the quiet sense that if I close this tab, I might not find it again.

So the tab stays open.

Then another one stays open.

Then the browser becomes a parking lot for unfinished thoughts.

A session-based history tool can reduce that pressure. If I trust that the group of pages can be recovered later, closing tabs feels less like losing work.

That is one of the emotional goals behind Browser Memory.

I want the browser to feel less fragile.

If I spent thirty minutes researching something, that work should not disappear just because I cleaned up my tabs.

Sessions are not bookmarks

Bookmarks are still useful, but they solve a different problem.

A bookmark says, "I know this page is worth saving."

A session says, "This is what I was doing."

That distinction matters because I do not always know what is worth saving in the moment. Sometimes a page becomes useful only later. Sometimes the important thing is not one page, but the relationship between several pages.

Browser Memory sits in that middle space.

It catches the useful structure before I have decided what to permanently save.

Then, if something does become important, I can favorite it, add a note, move pages into a collection, or export the trail.

That feels closer to real work than asking every page to become a bookmark immediately.

The privacy side of sessions

Sessions can reveal more than individual URLs because they show patterns.

That is exactly why Browser Memory keeps the logic local.

If a tool is going to group my browsing into meaningful sessions, I do not want that grouping to require a cloud service. I do not want my research bursts sent to a server for analysis. I do not want a model deciding what my day was about from outside my browser.

Browser Memory uses local, deterministic rules. Your history stays on your device. Favorites, notes, collections, and settings live locally too.

The product is more useful because it sees context, but that context should still belong to the person browsing.

That line matters.

What building this changed for me

Building Browser Memory changed how I think about history.

I used to think of history as storage. A place where old pages go.

Now I think of it more like a recovery system.

The goal is not simply to keep every URL. The goal is to help me return to a thought, a task, a decision, or a trail of research without starting over.

That is why sessions became the heart of the product.

A flat list can store the past.

A session can help me continue it.

The bigger lesson

A lot of software becomes better when it uses the right unit.

A writing app is not only characters. It has drafts. A design tool is not only shapes. It has frames and components. A project tool is not only tasks. It has milestones, owners, and context.

Browser history should not only be URLs.

It should have sessions.

Because browsing is not random most of the time. It is messy, yes, but it is not meaningless. There are patterns in it. There are bursts of attention. There are topics and projects and questions we keep circling back to.

Browser Memory is my attempt to make those patterns visible.

Not by making history more complicated.

By finally organizing it around the way we already browse.