Why Browser History Matters in Forensic Investigations
Browser history is among the most probative digital evidence in civil and corporate investigations. It reveals intent, knowledge and activity patterns that no other artifact type can match. A user's browsing history shows what they searched for, what they read, what they downloaded and when they did each of these things.
In employment disputes, browser history can demonstrate that an employee accessed competitor websites, job boards or confidential file-sharing services during work hours. In insurance fraud cases, it can reveal travel bookings, social media activity or financial transactions that contradict a claimant's sworn statements. In family law matters, browser history can be relevant to custody evaluations and financial disclosure.
The forensic value of browser data extends beyond simple URL history. Bookmarks indicate sustained interest in a topic. Downloads show what files the user deliberately saved. Cached data reveals content that was rendered in the browser even if the user did not intentionally save it. Together, these four artifact types construct a detailed picture of a user's online activity over weeks, months or years.
Courts have consistently admitted browser history evidence when it is collected using forensically sound methods. The key requirements are: read-only access to the source data, documented chain of custody, accurate timestamp interpretation and reproducible extraction methodology. Every step in this guide is designed to meet those requirements.
Where Browsers Store Their Data
Every modern browser stores its data in structured database files on the local file system. Understanding these storage locations is fundamental to browser forensics, whether you are performing manual extraction or using automated tools.
Chromium-Based Browsers
Google Chrome, Microsoft Edge, Brave, Opera and Vivaldi are all built on the Chromium engine. They share the same database schema with minor variations. The core artifacts are stored in SQLite databases within each user's profile directory.
| Browser | Windows Default Path | Key Database Files |
|---|---|---|
| Google Chrome | %LOCALAPPDATA%\Google\Chrome\User Data\Default\ |
History, Bookmarks, Cookies, Login Data |
| Microsoft Edge | %LOCALAPPDATA%\Microsoft\Edge\User Data\Default\ |
History, Bookmarks, Cookies, Login Data |
| Brave | %LOCALAPPDATA%\BraveSoftware\Brave-Browser\User Data\Default\ |
History, Bookmarks, Cookies, Login Data |
| Opera | %APPDATA%\Opera Software\Opera Stable\ |
History, Bookmarks, Cookies, Login Data |
| Vivaldi | %LOCALAPPDATA%\Vivaldi\User Data\Default\ |
History, Bookmarks, Cookies, Login Data |
The History database contains the urls table (visited URLs with visit counts) and the visits table (individual visit records with timestamps). The Bookmarks file is JSON, not SQLite. Chromium timestamps are stored as microseconds since January 1, 1601 UTC. To convert to Unix time, subtract 11644473600000000 and divide by 1000000.
Mozilla Firefox
Firefox uses a different database schema and profile directory structure. Each Firefox profile is stored in a randomly named directory like xxxxxxxx.default-release under the Firefox profiles root.
On Windows, profiles are stored at %APPDATA%\Mozilla\Firefox\Profiles\. The profiles.ini file in the parent directory maps profile names to their randomly named directories. The primary database for history and bookmarks is places.sqlite. Firefox timestamps use PRTime format: microseconds since January 1, 1970 UTC.
The moz_places table contains URLs and their associated metadata. The moz_historyvisits table contains individual visit records with timestamps and visit types. Bookmarks are stored in the moz_bookmarks table, which references moz_places for the URL data.
Tor Browser
Tor Browser is a hardened Firefox fork configured with aggressive privacy defaults. It stores data in a Browser\TorBrowser\Data\Browser\profile.default directory. By default, Tor Browser clears all browsing data when closed. The places.sqlite file exists but is emptied on shutdown.
Forensic value from Tor Browser typically comes from three scenarios: the browser is still running and has not been closed, the browser process was terminated abnormally without cleanup, or the user modified default privacy settings to retain some data. In these cases, the places.sqlite file may contain recoverable browsing records.
SQLite Databases: The Forensic Foundation
SQLite is the storage engine used by every modern browser for structured artifact data. Understanding how SQLite stores and deletes data is critical for browser forensics.
A SQLite database is a single file that contains multiple tables organized in B-tree pages. When a record is deleted, SQLite marks the page space as free but does not overwrite the data. This means deleted browser history records may persist in the free pages of the database file until those pages are reused by new records. The SQLite VACUUM command and the auto_vacuum pragma affect this behavior. Chrome enables auto_vacuum on some databases, which reduces but does not eliminate the potential for deleted record recovery.
For active record extraction, which is what Sherlock Browser Viewer performs, you query the SQLite database using standard SQL statements. The database file must be copied before querying on a live system, because opening a SQLite database creates a write-ahead log (WAL) file and a shared-memory (SHM) file that could modify the source directory. This is why forensically sound tools copy the database first and query the copy.
Manual vs. Automated Browser History Extraction
There are two fundamental approaches to browser history extraction: manual and automated. Each has its place in forensic practice.
Manual Extraction
Manual extraction involves locating the browser database files, copying them to a working directory and querying them with a SQLite client such as sqlite3 or DB Browser for SQLite. This approach gives the examiner complete control over the queries and full visibility into the database schema.
A typical manual extraction of Chrome browsing history involves these SQL queries:
-- Extract browsing history with timestamps
SELECT urls.url, urls.title, urls.visit_count,
datetime(visits.visit_time/1000000-11644473600, 'unixepoch', 'localtime') as visit_date
FROM urls
INNER JOIN visits ON urls.id = visits.url
ORDER BY visits.visit_time DESC;
-- Extract bookmarks (from Bookmarks JSON file, not SQLite)
-- Requires JSON parsing, not SQL
-- Extract downloads
SELECT target_path, tab_url, total_bytes,
datetime(start_time/1000000-11644473600, 'unixepoch', 'localtime') as download_date
FROM downloads
ORDER BY start_time DESC;
The advantage of manual extraction is precision. You control exactly what data is queried and how timestamps are converted. The disadvantage is that it requires technical expertise, is time-consuming when multiple browsers and profiles are involved and is prone to error in timestamp conversion formulas.
Automated Extraction with Sherlock Browser Viewer
Automated extraction using Sherlock Browser Viewer follows a four-step process that handles all of the technical details described above.
- Install Browser Viewer. Download from the Sherlock Forensics website. The Free edition requires no license key. Run the installer and launch the application.
- Click Scan Computer. The tool automatically detects all installed browsers and their profile directories. It identifies Chrome, Firefox, Edge, Brave, Opera, Vivaldi, Tor Browser and Chromium installations across all user accounts.
- Filter to relevant timeframe. Use the date range filter to narrow results to the period under investigation. This eliminates irrelevant browsing data and focuses the output on the timeframe that matters for your case.
- Export CSV with Forensic Edition. The Forensic Edition ($29 USD) generates structured CSV files with ISO 8601 timestamps. Each browser and artifact type produces a separate CSV file. These files integrate with timeline analysis tools and eDiscovery platforms.
The automated approach handles timestamp conversion for both Chrome epoch and Firefox PRTime formats. It resolves Firefox profile directories by reading profiles.ini. It copies database files before querying them. It handles multi-profile browsers where a single Chrome installation may contain several user profiles with separate history databases.
Legal Considerations for Browser History Extraction
Browser history extraction raises legal considerations that vary by jurisdiction. The following is general guidance, not legal advice. Consult with counsel in your jurisdiction before performing browser examinations.
- Consent-based examination
- When the device owner or authorized user consents to the examination, browser history extraction is generally permissible. Document the consent in writing before beginning the extraction. Corporate devices typically fall under an employer's right to examine company-owned equipment, especially when an acceptable use policy is in place.
- Court-ordered examination
- When a court order or warrant authorizes the examination, the scope of browser history extraction should be limited to what the order specifies. If the order authorizes examination of "internet activity" for a specific date range, extract only that date range. Sherlock Browser Viewer's date filter supports this requirement.
- Employee monitoring and privacy law
- Canadian PIPEDA and provincial privacy legislation impose requirements on employer monitoring of employee internet activity. In many provinces, employees must be notified that their internet usage may be monitored on company equipment. European GDPR imposes similar requirements. Browser history extraction during an investigation should be conducted within the framework of existing privacy policies and legal advice.
- Chain of custody documentation
- Document who extracted the data, when, from which computer, using which tool and which version. Record the system clock at the time of extraction. Preserve the original browser database files alongside the CSV exports. This documentation is essential for admissibility.
Browser Artifact Analysis: Beyond Simple History
Effective browser forensics goes beyond listing visited URLs. The four artifact types that Sherlock Browser Viewer extracts each tell a different part of the investigative story.
Browsing history shows what the user visited and when. The visit count indicates how frequently a site was accessed. The transition type (typed, link, bookmark, redirect) reveals how the user arrived at the page. A typed URL indicates deliberate navigation. A redirect may indicate ad traffic or automatic forwarding.
Bookmarks indicate sustained interest. A user who bookmarks a competitor's product page or a job listing is demonstrating intent beyond casual browsing. Bookmark creation dates and modification dates provide additional timeline data.
Downloads show what the user deliberately saved to their local system. Downloaded files may include confidential documents, competitor materials, personal files or tools. The download URL identifies the source. The local file path shows where the user saved it. Cross-referencing download timestamps with browsing history reveals the context of each download.
Cached data reveals content that was rendered in the browser regardless of whether the user intended to save it. Web pages, images and documents viewed in the browser are cached locally for performance. Cache entries include access timestamps that may reveal browsing activity even when history has been cleared, because users often clear history without clearing the cache.
Common Challenges in Browser Forensics
Several challenges arise regularly in browser forensic examinations. Understanding them beforehand improves your examination methodology and strengthens your reporting.
- Private browsing / Incognito mode: Chrome Incognito, Firefox Private Browsing and similar modes do not write history to the SQLite database. Artifacts from private sessions are held in memory and discarded when the private window closes. No browser history extraction tool can recover private browsing data from disk after the session ends.
- Browser history clearing: Users can manually clear browsing data through browser settings. When cleared, records are deleted from the SQLite database. Some deleted records may be recoverable through SQLite carving, but this requires disk-level forensic analysis beyond what browser artifact tools provide.
- Multiple user profiles: Chrome and other Chromium browsers support multiple profiles within a single installation. Each profile has its own History database. An examination that only checks the Default profile may miss relevant data in other profiles. Sherlock Browser Viewer scans all profiles automatically.
- Synced browsing data: Chrome Sync, Firefox Sync and Edge Sync replicate browsing data across devices. History on the examined computer may include entries from other devices. The
visitstable includes afrom_visitfield and visit source metadata that can help distinguish local visits from synced entries. - Timestamp interpretation: Chrome and Firefox use different epoch values and microsecond precision. Converting these to human-readable formats requires the correct formula for each browser. An error in timestamp conversion can undermine the credibility of your entire examination.