Top 10 History Guide
Browsing history is a mess if you don't manage it. Most people treat their browser history like a trash can and then wonder why Chrome eats 4 GB of RAM. I've been cleaning up history dumps for years, usually for clients who lost an entire SQLite database and needed forensic reconstruction. Here's what actually works. Not a listicle. A functional breakdown of the things that matter when you're dealing with browser history at any scale. 1. Know your storage format. Chrome, Edge, and Brave all store history in an SQLite file called History with no extension, sitting in the user profile directory. Firefox uses places.sqlite. Safari on macOS stores its data in a binary plist inside the Container folder, which is a completely different beast. Trying to query a Safari history file with a tool built for Chrome will fail immediately.
2. Always copy before you touch. I once tried to run a query against someone's live Chrome history file while the browser was running. The database returned corrupted results because Chrome holds a write lock and writes to a journal file simultaneously. I wasted an hour chasing phantom timestamps. Copy the file first, close the browser, then work on the copy. Takes three seconds. 3. The URL column is not reliable by itself. Chrome stores URLs with some characters percent-encoded and others not, depending on when they were written. If you're writing a script to find duplicates or filter patterns, always normalize with unquote() before comparing. Otherwise you'll miss matches on URLs with encoded spaces or ampersands. 4. Visits and visits_source tables are separate for a reason. The main visits table tells you when a page was loaded. The visits_source table (or the visit_duration field in newer Chrome versions) tells you how long the user actually stayed on the page. These two numbers rarely agree. A redirect from a tracking pixel might show a 0.01 second visit but register as a full page load. Don't conflate them.
5. Timestamps are in Unix epoch microseconds. This trips people up constantly. A value like 1718438291000000 needs to be divided by 1,000,000 to get seconds, then converted. Python: datetime.utcfromtimestamp(ts / 1000000). JavaScript: new Date(ts / 1000). Do not skip the division step. I've seen scripts output dates in the year 54,000 because of this. 6. Incognito history doesn't exist in the standard file. This is obvious but worth stating plainly. If someone claims they can pull incognito browsing from a Chrome profile, they're either lying or they have a separate monitoring tool already installed on the machine. There's no backdoor in the SQLite file. 7. The last_visit_time field is per-URL, not per-session. It tracks the most recent time that specific URL was visited. If someone visits the same page every day for a year, the timestamp only shows the last visit. You need the full visits table to reconstruct the pattern. Beginners often query just the URL table and conclude someone only visited a site once.
Get the Full Details
8. Cache files are more useful than you'd expect. The Chrome cache directory contains actual copies of page resources, including sometimes the full HTML of pages that have since been taken down. I recovered a defunct company's entire product catalog from cache files two years after they shut down their domain. The history file only had dead links. 9. Bookmarks contain data the history file doesn't. If someone visited a page but never bookmarked it, it's in history. But if they bookmarked something and never visited it recently, it might not show up in a recent-history search. Always cross-reference the Bookmarks JSON file. It's plain text and trivially parseable. 10. File locking and encryption vary by platform. On Windows with BitLocker enabled, the history file is readable once the volume is unlocked. On macOS, FileVault encrypts the entire home directory, so the file is only accessible after login. Linux users typically have no disk encryption by default, which makes forensic access trivially easy. Keep this in mind before assuming you can extract a history file from a powered-off machine.
When this approach fails entirely
There's a scenario where none of this works: enterprise-managed devices. If the browser is controlled by a Microsoft Intune policy or a Jamf profile, Chrome may be writing its history to a cloud-backed sync account rather than locally. In my experience, about 30% of corporate devices I've audited fall into this category. The local history file is either empty or contains only a few days of cache. You need to pull from the sync account or the endpoint management console instead. No amount of SQLite querying will help you there. Another hard failure point: Chromium-based browsers with the "Clear browsing data on exit" policy enabled. The history file exists but gets truncated every session. You're essentially working with a rolling 24-hour window. I ran into this with a client who suspected their employee was visiting inappropriate sites. The history showed nothing. It turned out the browser was configured to wipe on close, but the employee was using a second browser without that policy. Check for multiple browsers before concluding there's no data.
A practical workflow
Here's what I actually do when I start a history analysis, and it takes me about 15 minutes for a standard single-user profile: Copy the History file from the profile directory to a working folder. Open it with DB Browser for SQLite or run a quick Python script. Pull all visits from the last 90 days. Group by hostname. Sort by visit count and timestamp spread. Flag any hostnames that appear during unusual hours or match known suspicious patterns. Cross-reference with the Bookmarks file. Export the findings to CSV. A typical query looks like this:
SELECT h.url, h.title, datetime(v.visit_time/1000000-11644473600, 'unixepoch', 'localtime') as visit_time FROM visits v JOIN urls h ON v.url = h.id WHERE v.visit_time > (strftime('%s', 'now') - 7776000) * 1000000 ORDER BY v.visit_time DESC LIMIT 500; Adjust the timestamp offset for your timezone. The 11644473600 value accounts for the difference between Windows FILETIME epoch and Unix epoch. Skip it and your dates will be off by roughly 112 years. If you need the raw files, the Chrome history database is located at C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Default\History on Windows, ~/Library/Application Support/Google/Chrome/Default/History on macOS, and ~/.config/google-chrome/Default/History on Linux. Firefox equivalents use the profile path found in about:profiles.
Most people overcomplicate this. The data is right there in a single SQLite file. The problem is never the tool, it's knowing which fields actually matter and not trusting the first query result without cross-checking.
