Clearing browser history doesn’t clear the cache. Most users don’t know that.

Chrome’s cache system was designed to speed up web browsing by storing copies of website resources locally. From a forensic standpoint, it’s a parallel record of online activity that operates independently of the browsing history database — and it often survives history-clearing events that investigators assume wiped the slate clean.

For examiners working civil investigations, employment matters, or any case where web activity is relevant, Chrome’s cache can reconstruct visited URLs, approximate visit times, and in some cases recover the actual content of pages the user visited. This guide covers where to find it, how to parse it, what survives incognito mode, and how to extract timestamps and URLs for use as evidence.

What Chrome’s Cache Actually Contains

Chrome caches web resources to reduce load times on repeat visits. That means storing local copies of:

Each cached resource is associated with a URL and a set of timestamps: when the resource was first fetched, when it expires, and when it was last used. These timestamps are your forensic hooks.

The cache doesn’t store a tidy list of “visited sites” the way the History database does. Instead, it stores the individual components that make up pages. A single page visit might generate dozens of cache entries — one for the HTML, several for images, one for the site’s JavaScript bundle, etc. Reassembling these into a coherent visit timeline is the core analytical task.

One important distinction: the cache is not a duplicate of browsing history. A resource cached from one visit may be served to the user on subsequent visits without creating new cache entries or new history entries. The timestamps in the cache reflect the first fetch, not necessarily the most recent visit.

Cache Directory Locations by Operating System

Windows

Chrome’s cache on Windows lives in the user’s AppData directory. The full path:

“`
C:\Users\[Username]\AppData\Local\Google\Chrome\User Data\Default\Cache\Cache_Data\
“`

For non-default profiles, replace `Default` with the profile name (`Profile 1`, `Profile 2`, etc.):

“`
C:\Users\[Username]\AppData\Local\Google\Chrome\User Data\Profile 1\Cache\Cache_Data\
“`

The `AppData` folder is hidden by default. In an investigation, access it directly via path or enable hidden file visibility. If you’re working from a forensic image, the path maps directly — the volume letter will differ, but the directory structure is identical.

macOS

On macOS, Chrome cache lives in the user’s Library folder, which is also hidden by default:

“`
/Users/[Username]/Library/Caches/Google/Chrome/Default/Cache/Cache_Data/
“`

The Library folder can be revealed in Finder with Shift+Cmd+G and typing the path, or accessed directly from a forensic image or mounted volume.

Linux

On Linux distributions, Chrome (and Chromium) store cache in the hidden `.config` directory:

“`
/home/[username]/.config/google-chrome/Default/Cache/Cache_Data/
“`

Chromium uses `.config/chromium/` instead of `.config/google-chrome/`. This matters when the investigated machine runs Chromium rather than Google Chrome — the data format is identical but the path differs.

Understanding the Cache File Structure

Chrome uses a custom file format for its disk cache. The `Cache_Data` directory contains:

The block files use a proprietary binary format. You can’t open them in a text editor and read them — you need a cache parser to extract meaningful content.

One thing worth noting: Chrome periodically rewrites these files during normal operation. The `f_` files for individual resources are more stable, but the index and block files are actively maintained by Chrome. If you’re examining a live system, capture the cache directory as soon as possible after securing the device.

Cache Parsing Tools

ChromeCacheView (NirSoft)

NirSoft’s ChromeCacheView is a free Windows utility that parses Chrome’s cache and displays results in a sortable table. For each cache entry, it shows:

ChromeCacheView is widely used and produces output you can export to CSV for further analysis. Its simplicity is a strength — the interface is clear, the output is easy to document, and opposing experts can verify your work using the same free tool.

Hindsight

Hindsight is an open-source Python tool designed for Chrome forensics broadly — it analyzes history, downloads, cookies, and cache together. The advantage over ChromeCacheView is integration: Hindsight correlates cache data with history records, giving you a more complete picture of web activity from multiple data sources simultaneously.

Hindsight outputs to SQLite or XLSX, making it easy to import into timeline analysis tools. For cases where you’re building a comprehensive web activity timeline, Hindsight is often the better starting point.

FTK and Axiom

Both FTK and Magnet AXIOM parse Chrome cache as part of their broader browser artifact analysis. If you’re already running a full forensic examination with one of these platforms, Chrome cache is included in the standard browser artifacts output. The advantage is workflow integration — you don’t need a separate tool, and the results are already in your case database.

For standalone cache analysis or when you need to verify results from a commercial tool, ChromeCacheView or Hindsight as a secondary check is good practice.

What Survives Incognito Mode

This is the question clients ask most often, and the honest answer is: less than normal browsing, but not nothing.

Chrome’s incognito mode explicitly avoids writing to the browser’s history database, download list, or cookies. But the interaction with the cache is more nuanced.

By default, incognito mode does not write to the on-disk cache. Chrome uses a separate in-memory cache for incognito sessions that’s discarded when the window closes. So in a standard incognito session, the `Cache_Data` directory doesn’t contain records of incognito activity.

However, several conditions can cause cache artifacts from incognito sessions to appear on disk:

Pinned resources. Certain service worker registrations and pre-fetched resources can persist across incognito sessions under specific circumstances, particularly in older Chrome versions.

Operating system-level swap files. When physical RAM fills up, the OS may swap memory to disk. An active incognito session’s cached content can end up in pagefile.sys or hiberfil.sys on Windows, or swap partitions on Linux. This is volatile and not guaranteed to persist, but it’s worth examining in cases where incognito activity is suspected.

Crash reports and GPU cache. Chrome’s GPU cache and shader cache don’t honor incognito restrictions in all versions. These caches are in adjacent directories and can contain artifacts of sessions that were otherwise incognito.

Enterprise policy overrides. Some organizations configure Chrome via enterprise policy to disable or modify incognito restrictions. In an employment investigation, check whether the organization had Chrome configured via Group Policy or Chrome management.

The takeaway: don’t assume incognito means nothing is recoverable. But also don’t overstate what the cache contains. Document precisely what you found and where, and let the evidence speak for itself.

Timestamps: What They Mean and What They Don’t

Chrome cache timestamps require some care to interpret correctly. Each cached resource can have several timestamps:

Creation time / First fetch. When Chrome first downloaded this resource from the server. This is the most forensically significant timestamp — it marks the earliest possible time the user visited the page that required this resource.

Last used time. When Chrome last served this resource to the browser, whether from cache or by revalidating with the server. If a user returns to the same site multiple times, this timestamp updates while the creation time stays fixed.

Server last-modified. The timestamp the web server reported for this resource in its HTTP response headers. This is the time the resource was last changed on the server, not when the user visited. Don’t confuse these — a web server’s last-modified timestamp for a JavaScript file tells you nothing about when the user visited the site.

Expires / Max-age. How long Chrome is instructed to treat this resource as fresh. Not directly forensically relevant, but it tells you something about whether a new request would have been made on a subsequent visit.

For timeline reconstruction, use the creation time as the “visited no later than” marker. A cached resource with a creation time of Tuesday at 2:00 PM proves the page was visited on or before Tuesday at 2:00 PM. It doesn’t prove the user visited at exactly that time — they could have visited the day before and the cache entry was created then.

Cross-reference cache timestamps against browser history database timestamps, download records, and any system event logs to build a corroborated timeline.

URL Reconstruction from Cache Artifacts

Sometimes the cache entry’s URL field alone is enough. Other times — particularly with complex web applications — the URL in the cache is a resource URL rather than the page URL the user navigated to.

For example: a user visits `https://cloudservice.example.com/documents/confidential-report.pdf`. Chrome might cache the PDF file itself, the site’s CSS, and various JavaScript files. The PDF file’s cache entry has the URL you want. The CSS and JavaScript files have generic URLs that appear on many pages of that site.

In practice, this means:

  1. Filter cache entries by content type. HTML and PDF entries are higher-value than JavaScript and CSS.
  2. Look at `Referer` headers preserved in the cache metadata. Some cached resources preserve the page URL that requested them.
  3. Correlate with the History database. If history hasn’t been cleared, the cache timestamps and history timestamps together place the user at a specific URL at a specific time.
  4. Look at file naming patterns. Direct-access URLs for files (like the PDF example) often appear verbatim in cache entries.

The [browser history reconstruction article](/browser-history-reconstruction-across-profiles/) covers how multi-profile and multi-browser analysis integrates with cache examination for complex cases.

Frequently Asked Questions

Does clearing Chrome’s browsing history also clear the cache?

Not by default. Chrome’s “Clear browsing data” dialog has separate checkboxes for “Browsing history” and “Cached images and files.” A user who clears history but leaves the cache checkbox unchecked leaves all cache artifacts intact. Even users who check the cache option may not fully clear it — Chrome sometimes takes time to purge entries, and older entries may persist briefly. In practice, you’ll often find cache artifacts from periods where history has been cleared.

Can Chrome cache analysis reveal content from HTTPS sites?

Yes. HTTPS encrypts data in transit — between the browser and the web server. Once the data arrives at the browser, Chrome decrypts it and may cache it locally in plaintext. The encryption that protects data in transit doesn’t protect cached copies on disk. A forensic examiner with access to the local filesystem can recover cached content from HTTPS sites in the same way as from HTTP sites.

How far back does Chrome cache typically go?

It varies by cache size settings and browsing volume. Chrome’s default cache size is limited (typically 80MB-1GB depending on available disk space), and it uses a least-recently-used eviction policy. High-volume browsing fills the cache faster and evicts older entries sooner. In practice, examiners often find cache entries going back weeks or months for normal users, but heavy browsers may see a shorter retention window. For any given case, report what you found rather than speculating about what might have been evicted.

Are Chrome cache artifacts from other user profiles separated from the default profile?

Yes. Each Chrome profile maintains its own separate cache directory. A machine with three Chrome profiles has three separate cache directories. This is forensically significant in cases involving shared devices — profile separation means you can sometimes attribute specific web activity to a specific profile, which can help establish which user account performed the activity. However, profile selection is easy to change, and a user can access any profile on a device they control. Attribution of a profile to a specific person requires corroborating evidence beyond the profile data itself.

What’s the best way to document cache findings for a legal proceeding?

Start with a hash of the cache directory contents before analysis. Use a tool that generates an export (CSV or database) of its findings, and hash that output file as well. In your report, document the tool name and version, the path from which you acquired the cache, the date and time of acquisition, and your methodology for selecting and interpreting the entries you’re presenting. For specific entries you’re relying on as evidence, include the full URL, content type, and creation timestamp. Avoid conclusions that overstate what the timestamps prove — “the cache entry was created no earlier than [date]” is more defensible than “the user visited this site on [date].”