browserforensics
Back to all articles

Chrome Top Sites and Favicons forensics

2026-06-21 · 3 min

Two of the smaller files in a Chromium profile punch above their weight when the main History database has been wiped. Top Sites keeps a ranked list of frequently-visited pages, and Favicons maps page URLs to the icons the browser cached for them. Neither is a full timeline, but both corroborate which domains the user actually saw — and they often survive a history clear because Chromium maintains them separately.

Top Sites

Top Sites is a small SQLite database holding the "most visited" tiles you see on the new-tab page. The table that matters is top_sites:

  • url — the page URL of the tile.
  • url_rank — the position in the ranking (lower is more frequent).
  • title — the page title at the time the tile was generated.

This is a compact, pre-computed list of the sites the user goes to most, derived from but independent of the full History database. When someone clears history but the profile is otherwise intact, top_sites can still hand you the top of their browsing habits — domain, rank and a human- readable title — in a few rows. It is not a visit log: there are no per-visit timestamps here, just the ranking snapshot. Treat it as corroboration, not as a count.

Favicons

Favicons is a separate SQLite database that caches site icons. Three tables do the work:

  • favicons — one row per icon, keyed by id, with url holding the icon's own URL (e.g. https://example.com/favicon.ico).
  • favicon_bitmaps — the actual image: image_data (the bytes), width / height, and last_updated.
  • icon_mapping — the join table linking a page_url to an icon_id.

The forensically interesting part is icon_mapping. Each row ties a page the browser rendered to the icon it fetched for that page. That page_url → icon link is direct evidence that the domain was visited: the browser does not cache a favicon for a page it never loaded.

These mappings frequently outlive a history clear. Favicons are refreshed and retained on their own schedule, so wiping History does not necessarily prune the Favicons database — meaning icon_mapping can list page URLs that no longer appear anywhere in the history tables. The last_updated field on the bitmap also gives you a rough "icon was current as of" timestamp, which can bracket when a page was last seen.

Using them together

Run the two against each other. top_sites.url and the page_url values in icon_mapping are both lists of domains the user visited, generated by different subsystems. Where they agree, you have two independent artifacts pointing at the same site. Where icon_mapping shows a page_url that is absent from a cleared History, you have a gap-filler: a domain that was visited and then deliberately or routinely scrubbed from the visit log.

The BrowserForensics tool parses Top Sites for rank, title and URL, and walks the Favicons database to surface the page → icon mapping directly, so you can read both lists side by side without writing SQL.

Pitfalls

  • Top Sites is a ranking snapshot, not a hit counter. A high url_rank means "frequent at the time the tiles were built," not a precise visit total.
  • A page_url in icon_mapping proves the page was loaded, but the last_updated on the bitmap is when the icon was fetched, not when the page was last visited — they are usually close, not identical.
  • Both files are SQLite, so copy the -wal and -shm sidecars too. Recent mappings may live in the WAL. See where browsers store their artifacts.
  • Some favicon_bitmaps rows hold no image data (placeholder or failed fetch). The mapping is still valid evidence of the visit even when the icon bytes are empty.

Further reading