Practice with national-level exam (FACT, FACT Plus, NET, CUET, etc.) mocks, learn from structured notes, and get your doubts solved in one place.
Where Chrome, Firefox, Safari and Edge keep history, cookies, cached objects and saved credentials; how to recover incognito traces; and how the artefacts read in Indian banking-fraud and phishing cases.
More than seven in ten Indian internet users open the web through Chrome, with Edge and Safari making up most of the rest and Firefox, Brave and Opera holding small but stubborn slices. For a digital forensic examiner that share matters because Chrome (and every Chromium browser that copies its layout) keeps the bulk of its history, cookies, autofill and saved credentials in a small set of SQLite files in one user-data directory. Recovering that directory is often the single richest artefact set on a seized Windows laptop in an Indian banking-phishing or credential-theft case, and a Section 63 BSA certificate over those files travels well into court if the chain of custody is clean.
Browser evidence is more than the URL bar. The Cache stores response bodies that may include the actual phishing page seen by the victim. Cookies and the Sessions folder can replay a logged-in session if collected before the suspect logs out. Local Storage and IndexedDB hold tokens for WhatsApp Web and Telegram Web that are equivalent to a logged-in handset. Incognito traces almost always survive in DNS cache, the pagefile, hibernation and registry MUICache, so the textbook line that incognito leaves zero trace is wrong in practice. This topic walks through where each artefact lives on Chrome, Firefox, Safari and Edge across Windows, macOS and Linux, the tools that read each store, and the Indian evidentiary rules that apply when the report reaches a trial court.
Chrome owns the share, Chromium owns the layout.
The browser share on Indian desktops sits around 70 percent Chrome, with Edge in the low double digits, Safari pinned to macOS, Firefox in single digits, and Brave and Opera making up the long tail. Mobile is heavier on Chrome and Safari. The forensic implication is clean: in most Indian cases the examiner is reading Chromium artefacts, with a Firefox or Safari profile as a secondary source.
| Browser | Engine family | Profile root (Windows) | Profile root (macOS) | Profile root (Linux) |
|---|---|---|---|---|
| Chrome | Chromium / Blink | %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\ | ~/Library/Application Support/Google/Chrome/Default/ | ~/.config/google-chrome/Default/ |
| Edge | Chromium / Blink | %USERPROFILE%\AppData\Local\Microsoft\Edge\User Data\Default\ | ~/Library/Application Support/Microsoft Edge/Default/ | ~/.config/microsoft-edge/Default/ |
| Brave | Chromium / Blink | %USERPROFILE%\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\ |
One profile, six core SQLite files, distinct evidentiary value.
The Chromium profile keeps its evidentiary core in a handful of SQLite databases. Each of them answers a different investigative question, and a careful examiner queries them in the order that builds the user-activity timeline cleanly.
| File | Key tables | What it proves | Timestamp format |
|---|---|---|---|
| History | urls, visits, visit_source, downloads, downloads_url_chains, keyword_search_terms, segments | URLs visited, search terms typed into the omnibox, downloads with target paths and referrers, frequency segments | WebKit time (microseconds since 1 January 1601 UTC) |
| Cookies | cookies (host_key, name, encrypted_value, creation_utc, expires_utc, last_access_utc) | Logged-in sessions, persistent identifiers, ad tracking, banking session cookies | WebKit time |
| Login Data | logins (origin_url, username_value, password_value (encrypted), date_created, date_last_used) | Saved credentials and which sites the user authenticated to | WebKit time |
| Web Data | autofill, autofill_profiles, credit_cards (encrypted), keywords |
Where the page actually rendered, not just where the URL was typed.
The History database tells you what URL was requested. The Cache, Local Storage and Sessions stores tell you what the user actually saw and what they were logged into when the lid closed.
The Chromium Cache is a key-and-body store, usually deflate-compressed, that holds full HTTP response bodies until they age out or the user clears them. In an Indian phishing case the Cache often contains the exact HTML and CSS of the lookalike banking page the victim saw, complete with hidden form actions pointing to the attacker's collector URL. ChromeCacheView from NirSoft and the Hindsight cache module both expand the cache into recoverable files keyed back to the original URL.
Same evidentiary value, different file names.
Firefox keeps its profile in a randomly-named directory under the Profiles folder (the random prefix discourages accidental shared profiles). The core stores are SQLite, like Chromium, but the names and the timestamp format differ.
Safari keeps its profile under ~/Library/Safari on macOS only. The core stores are SQLite and plist.
Edge ships Chromium under a Microsoft skin and writes the same layout under User Data. Adding to the Chromium baseline, Edge writes a Collections store (SQLite) and a Wallet store; on managed Indian banking-fraud cases where the suspect is a corporate user, Edge's enterprise-sync flags in Preferences often point to a corresponding Microsoft 365 tenant whose admin logs are themselves a parallel evidence source.
Why incognito leaves traces and why live capture beats post-mortem.
The marketing line says incognito and private browsing leave no trace. The forensic line says the opposite: the browser writes nothing to its own profile during a private session, but the wider system writes plenty. The competent examiner knows where to look.
What survives an incognito session on Windows:
Session recovery is the other half of this section. A cookie file collected from a live browser, together with the Sessions folder and a snapshot of Local Storage and IndexedDB, can be replayed into a fresh browser to resume the suspect's logged-in session. This matters in two scenarios. First, suspect-at-the-console arrest cases where the live machine is open to WhatsApp Web, the bank account, or the cloud workspace. Second, court-authorised intercept where the warrant covers continued access to a service that the suspect has already logged into. The forensic playbook is to image the running profile cold (not after closing the browser), preserve the Sessions folder and Local Storage in particular, and only then shut the machine down. In the Indian banking-phishing prosecutions of 2023-2024 (HDFC and ICICI lookalike-domain rings), the prosecution case in several charge sheets cited replayable session cookies recovered from suspect endpoints as corroboration of the operator's role; the evidentiary path used the Section 63 BSA certificate over the imaged profile and a separate certificate over the analyst's worksheet.
From acquisition to the witness box.
A working examiner usually combines a SQLite GUI with a Chromium parser and a cache viewer.
Chromium History timestamps are stored as:
| ~/Library/Application Support/BraveSoftware/Brave-Browser/Default/ |
| ~/.config/BraveSoftware/Brave-Browser/Default/ |
| Firefox | Gecko | %APPDATA%\Mozilla\Firefox\Profiles\<rand>.default-release\ | ~/Library/Application Support/Firefox/Profiles/<rand>.default-release/ | ~/.mozilla/firefox/<rand>.default-release/ |
| Safari | WebKit | (macOS only) | ~/Library/Safari/ | (not applicable) |
| Opera | Chromium / Blink | %APPDATA%\Opera Software\Opera Stable\ | ~/Library/Application Support/com.operasoftware.Opera/ | ~/.config/opera/ |
The Chromium layout repeats across Chrome, Edge, Brave and Opera, so a competent Chrome parser handles four of the top six browsers with no change. The differences sit at the edges: Edge writes a small number of extra preference files, Brave adds a Wallet directory and a Tor profile, Opera ships a separate VPN config that is worth pulling.
The second beat to remember is that a single seized laptop usually has more than one profile. The Default folder is one profile; Profile 1, Profile 2 and so on are alternative profiles, often used to separate work and personal accounts. Each profile has its own History, Cookies and Login Data. A common defence point in Indian phishing prosecutions is that the prosecution analysed only the Default profile and missed exculpatory activity under Profile 1. The acquisition checklist must list every profile directory it found.
| Names, addresses, phone numbers, partial card numbers offered by autofill |
| WebKit time |
| Top Sites | top_sites (url, rank, last_updated) | Frequently visited sites composite ranking | WebKit time |
| Network Action Predictor | network_action_predictor (user_text, url, number_of_hits, number_of_misses) | What the user typed into the omnibox that triggered autocomplete (often retains URLs never actually visited) | WebKit time |
The Network Action Predictor is the database most students forget and the one that surprises in court. It records partial user input that triggered a URL prediction, even when the user never pressed Enter. A suspect who typed the first six letters of a phishing-template hosting domain and then backed out leaves a row in network_action_predictor and nothing in History. The defence point that "the suspect never visited the site" can be answered by producing the predictor row.
Login Data stores password_value as a blob encrypted with the OS-level master key. On Windows the master key sits under DPAPI scoped to the user account; the examiner needs the user's Windows password or a memory-resident master key to decrypt. On macOS the master key sits under Keychain. On Linux the key lives in libsecret or kwallet. The presence of an encrypted blob is itself evidence of a saved credential; decryption is a separate step that often needs the live machine or a memory image.
Local Storage and Session Storage are LevelDB key-value stores, one directory per origin. IndexedDB is also LevelDB-backed and is the heavier of the two, often holding cached message bodies and contact lists for web apps. For WhatsApp Web the IndexedDB store at web.whatsapp.com holds the full local message cache and the session token; collecting it from a live machine produces an artefact equivalent to a logged-in WhatsApp handset, which is why preserving the live profile (rather than rebooting) matters when the suspect is caught at the console.
The Sessions folder is the artefact that wins the "what was open on screen" question. Current Tabs records the currently open tabs and their scroll positions; Current Session records the navigation history within each tab. Last Tabs and Last Session record the equivalents from the previous browser run. After a crash, Chrome restores from Current Session; the file therefore often survives even when the user thought they closed everything.
| Artefact role | Chrome / Edge / Brave | Firefox | Safari |
|---|---|---|---|
| History | History (SQLite) | places.sqlite | History.db |
| Cookies | Cookies (SQLite) | cookies.sqlite | Cookies.binarycookies |
| Saved credentials | Login Data (SQLite, DPAPI/Keychain/libsecret) | key4.db + logins.json (primary password optional) | Keychain (not in Safari profile) |
| Autofill | Web Data (SQLite) | formhistory.sqlite | (via Keychain) |
| Session state | Sessions folder (Current/Last) | sessionstore.jsonlz4 | LastSession.plist |
| Bookmarks | Bookmarks (JSON) | places.sqlite | Bookmarks.plist |
| Local Storage | LevelDB | webappsstore.sqlite | LocalStorage/<host>.localstorage |
| Timestamp epoch | WebKit (1601 UTC, microseconds) | PRTime (1970 UTC, microseconds) | Cocoa (2001 UTC, seconds) |
The cross-link to remember is the operating-system layer that backs these stores. Saved credentials on Safari, and to some extent on Chrome for macOS, are not in the browser profile at all; they sit in the macOS Keychain. The acquisition strategy on macOS therefore differs from Windows because the keychain database (login.keychain-db) is the credential source, not the browser file. See our macOS Forensic Artefacts topic for the keychain workflow end to end.
The Section 63 BSA workflow for browser-extracted evidence mirrors the workflow for any other electronic record: the original electronic record (the source device) does not need a certificate, but every copy produced in court does. The forensic image of the User Data directory is a copy; the Hindsight CSV exported from that image is a copy of a copy; both need a Section 63 certificate, and the safer practice is for the responsible official (typically the senior analyst or the section head) to certify the source image rather than the downstream artefacts. See our BSA Section 63 topic for the certificate template and the leading case law (Anvar P V; Arjun Pandit Rao Khotkar).
A practical Indian cross-link to keep in mind: browser artefacts in phishing prosecutions almost always sit next to email artefacts. The phishing message arrived by email; the click trail lives in the browser. The two evidence streams are read together. See our Email Forensics topic for the header-tracing methodology that pairs with browser analysis.