browserforensics
← Back to all articles

What is browser forensics?

2026-05-19 · 2 min

Browser forensics is the practical work of reading what a browser left on disk after a user, an attacker, or a piece of malware drove it. It is one of the highest-yield artifact classes on a typical workstation: rich, structured, and almost always queryable as SQLite or LevelDB without the browser running.

What you are actually pulling apart

Every modern browser keeps roughly the same data, organised differently per vendor. The categories you reach for in real cases:

  • History. urls and visits in Chromium, moz_places / moz_historyvisits in Firefox, history_items / history_visits in Safari. Includes visit count, transition type, and a per-visit timestamp.
  • Downloads. Source URL, mime type, target path, byte counts, start and end time. In Chrome the downloads_url_chains table preserves the redirect chain that led to the file.
  • Cookies. Domain, name, path, flags, creation / last access / expiry. The value is encrypted at rest on Chromium since v80; the metadata is not.
  • Autofill, saved logins, payment methods. Metadata in plain text, secrets encrypted with the user's DPAPI master key (Windows) or Keychain (macOS).
  • Bookmarks and sessions. Long-lived intent (bookmarks) versus very short-lived intent (tabs that were open at crash time).
  • Local Storage and IndexedDB. Web app state in LevelDB folders, where a surprising amount of evidence lives (logged-in identities for SaaS, draft messages, JWT tokens still parseable).

Why this is worth doing carefully

The combined timeline of "URL visited, file downloaded, cookie set, LocalStorage value written" frequently places an account behind an action to the second. That cross-artifact corroboration is what makes browser evidence stand up. Pair it with LNK metadata for downloaded files that were later opened, the MFT for the on-disk creation, and the USN journal for the rename/delete trail when someone tried to clean up.

Things that bite you

Treat copies as read-only. Always grab -wal and -shm sidecars alongside the main SQLite file or you will silently miss the most recent activity. Note timezones explicitly; Chrome uses the WebKit epoch (1601), Firefox microseconds since Unix, Safari Mac absolute time (2001). Mixing them is the single most common analyst mistake.

Further reading