How Google Chrome stores web history

In 2008 Google released most of Chrome’s source code as a project called Chromium under a BSD license. Chromium is essentially the same browser as Chrome, but lacks built-in automatic updates and Google branding [Chromium Developer Website].

Assuming the computer is running Windows XP, the Chrome default path to user data is:

C:\Documents and Settings\<User Name>\Local Settings\Application Data\Google\Chrome\User Data

For Windows Vista and Windows 7, the default path is:

C:\Users\<User Name>\AppData\Local\Google\Chrome\User Data

Chrome uses SQLite databases similar to Firefox but with notable differences explained below. All databases are stored in the directory Default, with history and web data being the most important databases stored here. Chrome does not add extensions to its files; but fortunately SQLite databases have a file header of “SQLite format 3” making them easy to recognise.

Chrome is not consistent with which datetime format it uses, some tables use standard Unix Epoch time (microseconds since 1st January 1970) whilst in others it uses its own variation of Windows Filetime (100 nanosecond intervals since 1st January, 1601 UTC divided by 10).


Similar to places.sqlite in Firefox, history contains a table of unique URLS visited called urls, and a table for each unique visit called visits. Also like Firefox, it is possible to trace a user’s exact path on the internet as Chrome also stores the referring URL and the visit type, which Chrome names transition. Tables below show the fields in urls and visits respectively.

idThe table’s primary key. This is used in a lot of other tables to reference this table.
urlStores a unique visited URL.
titleStores the URLs page title.
visit_countStores the total visit count for this URL.
typed_countStores the number of times the URL was typed manually.
last_visit_timeStores the last time the URL was visited. This is stored in Google’s own variation of time.
hiddenIndicates if the URL will be displayed by the autocomplete function. A value of 1 will keep it hidden and 0 will display it.
favicon_idA foreign key to the favicon table which stores the favicon for each URL.
Table URLS
idThe table’s primary key.
urlStores a foreign key to the urls table.
visit_timeStores the time the URL was visited in Google’s own variation of time.
from_visitStores the id from where the URL came from originally. If the URL does not have a referring URL this value is 0.
transitionShows how the URL has been accessed. Unlike Firefox which just gives a number to represent the type of transition, Chrome has some additional information such as whether or not this was a client or server redirect and if this is a beginning or end of a navigation chain. The transition is a long number, so to extract just the transition type number the variable CORE_MASK (0xFF) has to be used to AND with the transition value.

There are 11 page transition types, such as 0 – user followed a link, 1 – user typed in the URL and 6 – this is the user’s homepage/startpage.
segment_idStores the segment id. It is not clear what ‘segments’ are. There are tables called segments and segment_usage also in history, and they appear to store the domain names of accessed URLs along with a total visit count.

To see how these tables relate, see my earlier blog post on how Firefox stores web history.


web data stores logins and autofill data. The table logins stores usernames and passwords for URLs the user has asked to save data for. Only the password is stored encrypted. The table autofill stores values the user has used in forms. This is joined to autofill_dates which stores the last used date for the data. There are also tables called autofill_profiles and credit_cards which contain the user’s details and credit card information so they can be automatically added to web forms.


In the same folder are files named History-Index-YYYY-MM which stores the text-based contents of any website visited. This is used when the user searches through web history with key words. Chrome will search over the history index files to find any webpages that match. Over time these files can grow very large, to tens of Gigabytes. This has been issued as a bug in the browser, but can be of importance to a forensic investigator who can also do key word searches to get an idea of the contents of the pages the user was visiting.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s