A product-design look at Browser Memory and the idea that browser history should group pages by browsing sessions, not only by timestamps.

I kept asking myself one question while building Browser Memory:
What if Chrome's history page understood sessions?
Not in a complicated way. Not as a full productivity dashboard. Just enough to know that the seven pages I opened while debugging one problem belonged together.
That small idea changes the whole feeling of browser history.
Because the default history page is not wrong. It is just limited. It shows time, title, and URL. It lets me search. It gives me a record.
But it does not understand the unit that matters most when I am trying to recover work.
The session.
Chrome history already contains clues.
It knows when pages were visited. It knows which domains appeared close together. It knows the titles. It knows the order. It knows when there was a long gap and when there was a burst of activity.
That is enough to build a better interface.
The browser does not need to read my mind. It only needs to preserve patterns that are already visible.
If I open MDN, npm, GitHub, Stack Overflow, and a framework docs page in a short window, there is probably a reason. Even if the browser cannot know the exact reason, it can keep those pages near each other.
That is already a huge improvement over flattening them into a chronological list.
A session does not perfectly explain what I was doing.
But it gives the activity a container.
That container is useful because intention is often visible through proximity. Pages opened around the same time often belong to the same problem, comparison, decision, or curiosity.
When Browser Memory groups pages into sessions, it is not claiming to know everything. It is simply saying:
"These pages happened together. You might want to return to them together."
That is a modest claim, and modest claims are good in software that handles personal data.
It helps without pretending.
A flat history page pushes reconstruction onto the user.
If I need to remember a research trail, I have to scan rows and mentally group pages myself. I have to notice timestamps, domains, and surrounding pages. I have to rebuild the session from fragments.
That is work the interface could do for me.
Not perfectly. But enough.
Browser Memory exists because I got tired of doing that reconstruction manually. If the data already suggests a browsing burst, the interface should show the burst.
That is the difference between storage and memory.
Storage keeps the pieces.
Memory helps rebuild the scene.
One reason people keep too many tabs open is that tabs feel like active memory.
A tab is not just a page. It is a reminder. It says, "I was doing something with this."
History, by contrast, often feels like cold storage. Once a page lands there, the context is gone.
Sessions bring some of that context back.
If I close a group of tabs, I can still return to the group later. I can see the related pages, the order, the day, and the surrounding trail. I can favorite the session, add notes, or move useful pages into a collection.
That makes history feel less like a graveyard for old tabs and more like a recovery surface.
That feeling matters.
The session idea is also one of the reasons I avoided AI in Browser Memory.
The product does not need to make deep claims about what I was doing. It can provide useful structure from local signals.
Time gaps. Domains. Page titles. Repeated patterns. User notes. Favorites. Collections.
That is plenty for a first version.
AI might generate a nicer sentence, but a nicer sentence is not always the same as a better product. For browser history, I care more about privacy, speed, and predictability.
A deterministic session group is easy to understand. It is also easy to trust.
And trust is more important than theatrical intelligence here.
A session view is powerful, but it is not the only way people remember.
Sometimes I remember the date. Sometimes I remember the domain. Sometimes I remember a note I wrote. Sometimes I remember that I starred the page because I knew I would need it later.
That is why Browser Memory is not only sessions.
It has a timeline for day-based recovery. It has domains for source-based recovery. It has search for direct recovery. It has notes and collections for user-created context.
But sessions are the heart because they connect the others.
A timeline shows when the session happened. A domain appears inside the session. A note explains why a page mattered. A collection can pull important pages out of one or more sessions.
The session gives those pieces a natural home.
Once I started thinking in sessions, the product direction got simpler.
The question stopped being, "How do I make history more powerful?"
It became, "How do I help someone return to what they were doing?"
That is a better question.
It changes the feature list. Search is not just search. It is a doorway back into a session. Notes are not just notes. They are reminders attached to the browsing context. Collections are not just folders. They are a way to keep useful pages after the original session ends.
The whole product becomes more coherent when the goal is continuation.
I did not want sessions to feel like analytics.
I do not need charts judging how I spent the day. I do not need productivity scores. I do not need the browser telling me whether a session was valuable.
I just need the group.
Show me the pages. Give the session a useful title if possible. Let me open the pieces I need. Let me favorite it, note it, collect it, or export it.
That is enough.
A calm interface is better here because history is already noisy. The product should reduce the noise, not turn it into a dashboard full of pressure.
The more I worked on Browser Memory, the more I believed that sessions should have been part of browser history a long time ago.
Not because sessions are revolutionary.
Because they are obvious once you use them.
Browsing happens in bursts. People work across groups of pages. Useful context lives between tabs. A history page that ignores those relationships will always make users do extra work.
Browser Memory is my attempt to fix that for myself first.
If Chrome's history page understood sessions, closing tabs would feel less risky. Finding old research would feel less like detective work. A day of browsing would become easier to read.
That is the whole promise.
Not a smarter browser in the loud sense.
A browser that remembers the shape of what you were doing.

Browsing in bursts? Your history should group itself like you do. I do not browse in a straight line. I doubt most people do. I browse in bursts. A burst of research before building a feature. A burst of comparison before choosing a tool. A burst of debugging when something breaks. A burst of reading when one article...

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....

Local first, deterministic, and still smarter than chrome://history I like tools that are boring in the right places. That might sound like a strange way to describe a browser history replacement, but it is exactly how I think about Browser Memory. The product should feel useful. It should help me return to sessions,...