Chrome Web Data: autofill and saved cards

Most analysts grab History and Login Data and stop. The Web Data SQLite file sits in the same profile and is routinely ignored — yet it holds every form value the user typed, their saved addresses, names, emails and phone numbers, and their stored payment cards. It is an identity goldmine that often survives a history wipe.

Where it lives

Web Data is a SQLite database in the Chrome (or Edge) profile root, alongside History, Cookies and Login Data. Edge is byte-for-byte the same schema — it is Chromium underneath. Copy the file (and its -wal/-shm if present) before reading.

The autofill table

The autofill table is the quiet hero here. Every distinct value the user types into a named form field is recorded once, with a usage count and first/last-used timestamps.

Column	Meaning
`name`	the form field name (e.g. `email`, `q`, `search`)
`value`	the literal text the user typed
`count`	how many times that value was entered
`date_created`	first time typed — Unix seconds
`date_last_used`	last time typed — Unix seconds

This is search-box and form-field history, decoupled from page history. A q field with the value where to buy ... and a count of 12 tells you the user typed that query a dozen times, with exact bracketing timestamps — even if History was cleared. Note these are plain Unix seconds, not the WebKit/Chrome microsecond epoch used elsewhere.

Saved addresses and identities

Addresses live across a small cluster of tables keyed by a profile GUID:

Table	Holds
`autofill_profiles`	the address record (street, city, state, zip, country)
`autofill_profile_names`	first / middle / last name per profile
`autofill_profile_emails`	email addresses
`autofill_profile_phones`	phone numbers

Join them on the profile GUID and you reconstruct full identities the user saved for one-click form fill: real name, home or shipping address, email and phone. This is direct attribution evidence, all in cleartext.

Saved credit cards

The credit_cards table stores payment cards the user let Chrome remember:

Column	Encrypted?	Notes
`name_on_card`	no	cardholder name, cleartext
`expiration_month`	no	cleartext
`expiration_year`	no	cleartext
`card_number_encrypted`	yes	os_crypt AES-256-GCM blob
`use_count`	no	times the card was used to fill
`use_date`	no	last used

So even without decrypting anything, you already have the cardholder name, the expiry, and how often/when the card was used. Only the PAN itself is protected.

What's encrypted, and how

card_number_encrypted uses the same os_crypt scheme as cookie values and saved passwords: AES-256-GCM, with the key wrapped under DPAPI on Windows, the Keychain on macOS, or the keyring/peanuts fallback on Linux. Recover the os_crypt key once and you decrypt cookies, passwords and card numbers with it — there is no separate key for Web Data. The cardholder name and expiry around the encrypted number are plaintext regardless.

Forensic value

Identity attribution. Names, emails, addresses and phone numbers saved as autofill profiles tie a profile to a real person.
Typed-input recovery. The autofill table preserves search queries, usernames, recipient emails and other typed values — often the only surviving record after a history clear.
Financial linkage. Cardholder name plus the decrypted PAN (with the key) links the subject to a specific payment instrument; use_date and use_count add a usage timeline.

How the tool handles it

BrowserForensics parses autofill, the autofill_profiles* cluster and credit_cards entirely in your browser, joins the profile tables for you, and — when you supply the os_crypt key — decrypts card_number_encrypted to recover the full card number. Nothing leaves the page.

Pitfalls

autofill timestamps are Unix seconds; don't apply the WebKit microsecond conversion you use for History.
A non-empty card_number_encrypted with no key is just GCM ciphertext — record it as present, not as recoverable.
The newest entries can sit in the -wal; copy it alongside the main database or you lose recent autofill activity.