Chrome vs Firefox vs Safari: artifacts compared

The three major engines store the same conceptual data — history, cookies, credentials, cache, sessions — but in different files, different formats, and on different timestamp epochs. This post puts them side by side so you can jump straight to the right artifact in a profile you don't recognise. For the broader map of a profile folder, start with where browsers store their artifacts.

History

	Chrome / Edge (Chromium)	Firefox	Safari
File	`History`	`places.sqlite`	`History.db`
Format	SQLite	SQLite	SQLite
Tables	`urls`, `visits`	`moz_places`, `moz_historyvisits`	`history_items`, `history_visits`

All three are SQLite, so all three open read-only and query the same way. The column names and join keys differ, but the shape — a URL table joined to a visit table — is identical across vendors.

Cookies

	Chromium	Firefox	Safari
File	`Cookies` (`Network/Cookies`)	`cookies.sqlite`	`Cookies.binarycookies`
Format	SQLite	SQLite	Apple binary
Values	Encrypted (AES-GCM via `os_crypt`)	Cleartext	Cleartext
Metadata	Cleartext	Cleartext	Cleartext

Cookies are where the formats diverge hardest. Firefox keeps plain values in SQLite. Safari uses its bespoke Cookies.binarycookies container — binary, but cleartext. Chromium encrypts the value with AES-GCM keyed through os_crypt (DPAPI on Windows, the Keychain on macOS) while leaving the domain, name and flags readable. See browser cookies forensics for the per-field detail.

Passwords

	Chromium	Firefox	Safari
Store	`Login Data` (SQLite)	`logins.json` + `key4.db`	macOS Keychain
Encryption	`os_crypt`	NSS (master key)	Keychain (OS-level)
Browser file?	Yes	Yes	No

The important caveat is Safari: passwords live in the macOS Keychain, not in a Safari file at all, so there is nothing in the profile to parse. Chromium stores ciphertext in Login Data; Firefox splits the secrets between logins.json and the key4.db NSS key store.

Bookmarks

	Chromium	Firefox	Safari
Location	`Bookmarks`	inside `places.sqlite`	`Bookmarks.plist`
Format	JSON	SQLite (`moz_bookmarks`)	Binary plist

Firefox is the odd one out here: bookmarks share places.sqlite with history rather than living in their own file.

Cache

	Chromium	Firefox	Safari
Location	`Simple Cache` (`Cache_Data`)	`cache2/entries`	`Cache.db`
Format	Chromium Simple Cache	Firefox cache2	SQLite

Only Safari's cache is a tidy SQLite database. Chromium's Simple Cache and Firefox's cache2 are custom on-disk layouts of indexed entry files.

Sessions and tabs

	Chromium	Firefox	Safari
File	`Sessions`	`sessionstore.jsonlz4`	`LastSession.plist`
Format	SNSS	Mozilla LZ4-wrapped JSON	Binary plist

These hold the tabs that were open — short-lived intent that often matters most at the moment of an incident. Each vendor wraps it differently: Chromium's SNSS command stream, Firefox's LZ4-compressed JSON, Safari's binary plist.

Timestamp epochs

	Chromium	Firefox	Safari
Epoch	WebKit	PRTime	Mac absolute time
Base	1601-01-01 UTC	1970-01-01 UTC	2001-01-01 UTC
Unit	microseconds	microseconds	seconds

This table is the one to keep on hand. Mixing epochs is the single most common analyst error: a Chromium value read as Unix microseconds lands centuries off. The mechanics — including the per-table exceptions — are in browser timestamp formats.

What the tool parses and decrypts

BrowserForensics is 100% client-side: files are processed in your browser and never uploaded. Honest scope of what it does today:

Capability	Coverage
Parses	History, cookies, bookmarks, cache, sessions across all three browsers
Decrypts (Chromium)	Cookies, saved passwords, payment cards (via `os_crypt`)
Decrypts (Firefox)	Saved passwords (`logins.json` + `key4.db`)
Not decrypted	Safari Keychain passwords (OS store, not a browser file)

Decryption depends on having the key material — the Chromium os_crypt key or the Firefox NSS master key — alongside the artifact. Without it you still get all the cleartext metadata.