Browser Forensics - Free Online History, Cookie & Deleted-Record Analyzer
Browser Forensics
Rebuild a browsing timeline from a Chrome or Firefox profile database, inventory its cookies, find evidence that history was cleared, and recover deleted records - without uploading anything.
Drop a browser profile database here
Chrome History, Cookies, Login Data, or Firefox places.sqlite / cookies.sqlite
Choose databaseOverview
Which browser database this is, how it is laid out on disk, and whether anything about it suggests history was cleared or the file was edited.
History Timeline
Every address in the profile with its visit counts and last-visit time, plus the individual visit records showing how each page was reached.
Cookies
Every cookie in the store with its host, expiry and security flags. Values stay hidden until you choose to reveal one.
Downloads
What was downloaded, where it was saved, which page it came from, and whether the transfer actually finished.
Saved Logins
Which sites have a saved credential, under which username, and when it was last used. Passwords are never decrypted or displayed.
Bookmarks & Favicons
Bookmarks show intent, not just traffic - and a cached site icon with no surviving history entry is direct evidence that history was cleared while the icon cache was not.
Form Autofill
Values a form was filled with, how many times, and when - the value itself is shown, never a saved card or profile's encrypted side table.
Session Restore
What was open when the browser last closed - often a question nothing else in the profile can answer.
Deleted Records
Records recovered from pages the database has freed but not yet reused - best-effort carving, not a guaranteed undelete.
All Tables
Browse any table in the database directly, including ones this tool has no purpose-built view for.
Strings
Every run of readable text anywhere in the file, including regions no table points at any more.
Understanding Browser Artifact Forensics
Why Browsers Store History in SQLite
Chrome and Firefox both keep their profile data in ordinary SQLite database files - History, Cookies and Login Data for Chrome, places.sqlite and cookies.sqlite for Firefox - usually with no file extension at all. Because SQLite's on-disk format is fully documented and stable, those files can be read directly without the browser that wrote them, which is what makes a browser profile one of the richest and most commonly examined artifacts in a digital investigation.
Why Clearing History Leaves a Trace
Browsing history is stored twice over: one row per distinct address carrying a running visit counter, and one row per individual visit. Clearing a date range removes the individual visit rows but does not roll back the per-address counters, so a profile can end up claiming hundreds of visits while holding almost no visit records. That mismatch, along with gaps in the never-reused row ids and visit rows pointing at addresses that no longer exist, is what turns "the history looks empty" into positive evidence that it was deleted rather than never created.
What Happens to a Deleted Row
Deleting a row does not erase it. SQLite unlinks the page it lived on and adds that page to a "freelist" of space available for reuse, but unless the secure-delete setting is switched on, the bytes are left exactly as they were - often including the page's own internal structure. A freed page can therefore frequently be decoded like a normal one, recovering deleted rows complete with their original row ids and correct column boundaries. What is genuinely gone is anything whose page has since been handed back out and written over.
Why Chrome's Timestamps Start in 1601
Chrome inherits the Windows convention of counting time from 1 January 1601, in microseconds, while Firefox counts microseconds from the Unix epoch of 1970 and stores cookie expiry in plain seconds - three different units inside two databases that otherwise look alike. Reading a timestamp with the wrong assumption does not produce an error, it produces a confident and completely wrong date, which is why every timestamp shown here is converted according to the specific database it came from rather than a single global rule.