Excel Charts and Cached Plot Data: How xl/charts/chart*.xml Preserves numCache and strCache Values That Survive Source Deletion and Reveal the Numbers Behind Every Picture

A Chart Is Two Things: A Reference and a Copy

When a user selects a range and inserts a chart, Excel records two completely different descriptions of the same data. The first is a reference: a series formula such as Sheet1!$B$2:$B$13 that tells Excel where to look when it recalculates. The second is a copy: the actual values that lived in that range at the moment the chart was last saved, frozen into the chart part as a cache. Both travel inside the workbook, and they are stored in xl/charts/chart1.xml (with one numbered part per chart), wired to the worksheet through a drawing part and a chain of relationship files.

The cache exists for a sensible engineering reason. A chart that had to recompute every series from its source formulas on every open would be slow, and a chart whose source had moved, been deleted, or lived in a now-unreachable external file would simply fail to render. The cache makes charts fast and robust: Excel paints from the frozen copy first and only refreshes from the source when the data is present and a recalculation is triggered. The side effect is that every chart carries a self-contained snapshot of its underlying numbers — and that snapshot does not vanish when the source does. This is the same fundamental pattern as the pivot cache embedding a full copy of source data, applied to a layer almost nobody thinks of as a data store.

Inside chart1.xml: numCache, strCache, and the Series Formula

Each plotted series in a chart is a <c:ser> element, and inside it sit the two halves of the picture. The category axis values — the labels along the bottom — live under <c:cat> in a <c:strCache> (for text) or <c:numCache> (for numbers and dates). The plotted values — the bar heights or line points — live under <c:val> in a <c:numCache>. Each cache pairs a <c:f> formula reference with a list of <c:pt> points carrying the literal cached value at each index:

Three things leak from this one series. The series-title cache names the metric exactly as the author labelled it internally — True Gross Margin %, not whatever softened heading appears in the deck. The category cache carries verbatim labels, including the parenthetical Pinnacle Retail (at-risk) annotation that the author never intended for an outside reader. And the value cache holds 0.4131 and 0.0892 — the precise figures behind two bars whose axis might only show “41%” and “9%.” All of it is plain text, and all of it ships inside the chart whether or not the Margins sheet still exists.

Deleted, Hidden, or Linked Away: The Cache Stays

The dangerous property of the cache is that it is decoupled from the source. Three common workflows all leave the cached values fully intact while creating the impression that the data is gone:

• Deleting the source rows or sheet. An author builds a chart from a detailed working sheet, then deletes the sheet to “clean up” before sharing. The chart keeps rendering — from its cache — and the cache still holds every plotted number and label that the deleted sheet contained.
• Hiding the source sheet. Hiding a sheet removes it from the tab bar but not from the package, and in any case the chart never needed the visible sheet: it paints from the cache. The hidden values and the cached values are now two separate copies, both shipping.
• Breaking the link to an external workbook. A chart whose series point at another file via external references caches the last-seen values. Break the link and the formula goes inert, but the cache preserves the figures pulled from the other workbook — frequently a more sensitive source than the one being shared.

In each case the author performs an action that feels like removing data and reasonably concludes the workbook is clean. The chart still looks right, which reinforces the belief. But “the chart still looks right” is precisely the symptom of the problem: it looks right because the data is still there, frozen one layer down.

The Cache Is More Precise Than the Axis

A chart is a deliberately lossy presentation. An axis labelled in increments of ten thousand rounds away the last four digits; a percentage shown to the nearest whole number hides the decimals; a bar drawn to the edge of the plot area communicates “big” but not “47,318,994.” The cache, by contrast, stores the value at full precision exactly as it was computed. A reader who only sees the rendered chart sees the rounded story; a reader who reads <c:numCache> sees the exact figure.

This gap matters most for the kinds of numbers people deliberately blur in a chart. Revenue figures shown as a tidy bar carry their exact value in the cache. Headcount plotted as a trend line caches the precise count at each point. A margin chart that visually communicates “healthy” caches the figure to four decimal places, including the quarters where it was thin. The chart was designed to round; the cache refuses to. Anyone extracting the cache recovers the unrounded numbers the visual was meant to soften.

Series Formulas Map the Workbook’s Internal Structure

Alongside the cached values, each series keeps its <c:f> formula reference — the address the data came from. These references are a map of the workbook’s internal structure, and they survive even when what they point at does not. A formula such as 'Q3 Internal Working'!$F$2:$F$60 names a sheet that may have been deleted, telling a reader it once existed, that it had at least sixty rows of data, and what it was called. References to defined names expose the workbook’s named-range vocabulary; references to other files expose the network paths of external sources.

The combination is what makes the chart layer rich for an investigator. The cache says what the numbers were; the formula says where they lived and what the author called that place. A chart whose source sheet has been deleted still names the sheet, still records its row count, and still holds its values — a near-complete reconstruction of a tab the author believed was gone. The same self-documenting reference that makes the chart maintainable makes it a structural disclosure.

How the Chart Layer Wires Together

A chart is not anchored directly to a worksheet; it sits behind a short chain of parts, and any cleanup has to respect the whole chain or it produces a package Excel offers to repair. The worksheet references a drawing part (xl/drawings/drawing1.xml) through its rels file. The drawing part anchors the chart frame to a cell range and references the chart part (xl/charts/chart1.xml) through its own rels. The chart part holds the series, the caches, and the formulas — and may carry its own xl/charts/_rels/chart1.xml.rels pointing at a colour-style part, a chart-style part, or, for charts built from their own embedded mini-table, a xl/charts/chart1.xml companion data part.

Modern chart types add another wrinkle. Waterfall, treemap, sunburst, histogram, box-and-whisker, and funnel charts — the “extended” family — are stored in a parallel xl/charts/chartEx1.xml part using a different schema, and they keep their cached data inside a <cx:data> block rather than the classic numCache. A cleanup pass that only knows the classic chart schema walks straight past every extended chart and leaves its data fully intact, exactly the way a comment cleanup that only knows threaded comments leaves the legacy note layer untouched.

Reading the Cache Without Excel

Extracting a chart’s data needs only a ZIP reader and an XML parser. Walking every xl/charts/chart*.xml part and reading the cached points out of each series reconstructs the underlying table directly from the picture:

The script prints, for every series, its source references and the full list of cached values — titles, categories, and plotted numbers together. For ad-hoc inspection, renaming the file to .zip, expanding it, and grepping xl/charts/ for <c:v> surfaces every cached point in seconds. That is precisely what an opportunistic recipient does the moment a workbook with charts lands — the same trivial unzip-and-read move that exposes the shared-strings table.

What an Investigator Reconstructs From the Layer

From a single sweep through the chart parts of a workbook, a reader typically extracts:

• The full data table behind every chart, point for point, from the value and category caches — including charts whose source sheet has been deleted.
• Exact, unrounded figures that the rendered axis deliberately blurs.
• Internal metric names and candid category labels from the series-title and category caches.
• The names of deleted or hidden source sheets, from the surviving <c:f> formula references.
• The row count and column layout of those sheets, inferred from the reference ranges.
• Network paths and filenames of external source workbooks, from broken external references frozen into the formulas.
• Cached values pulled from external files the recipient was never meant to see, preserved after the link was broken.

The first three categories are the data and how it was framed; the last four are structure and provenance. Together they routinely reconstruct an entire analytical worksheet that the author believed they had removed from the file, leaving only the harmless-looking picture behind.

Why Document Inspector Never Touches It

Microsoft’s Document Inspector has checks for document properties, hidden sheets, comments, and several other layers — but it has no concept of chart-cache data. From the inspector’s point of view a chart is legitimate visible content the user deliberately created and wants to keep; stripping the data that makes it render would break the chart, so the inspector leaves it entirely alone. There is no “remove cached chart data” option because, by design, the cache is not treated as removable metadata at all.

That places chart caches in the same blind spot as table schemas and conditional-formatting rules: layers that carry real disclosure but that the inspector classifies as ordinary content. A workbook that has been “inspected and cleaned” ships every chart cache untouched. Hiding the source sheet does not help, deleting it does not help, and the one tool most users trust to find hidden data does not look here.

How to Actually Strip Cached Chart Data

There is no clean Excel UI action that removes a chart’s cache while keeping the chart, because the cache is what keeps it rendering. The realistic options trade off how much of the chart you need to preserve:

• Convert the chart to a picture. The most reliable defence: copy the chart and paste it back as an image. The picture renders identically but carries no numCache, no strCache, and no series formulas — only pixels. Confirm the image itself is clean, since pasted pictures travel through the media layer that can retain its own metadata.
• Keep the source, keep the chart, ship deliberately. If the chart must stay live, accept that its data ships and make sure every cached value is one you are content to disclose at full precision — including the categories and the series title.
• Rewrite the caches in code. For automated pipelines, parse each xl/charts/chart*.xml and chartEx*.xml, and either overwrite the cached points with rounded or redacted values or rebuild the chart against a sanitised summary range. This keeps a live, branded chart while removing the unrounded figures and the original references.

Whichever path you take, the extended chart family is the easy thing to miss: a sweep that only rewrites classic numCache elements leaves every waterfall, treemap, and histogram fully populated in its chartEx part. And remember the formulas: redacting the cached values while leaving the <c:f> references in place still discloses the structure and names of the source sheets. A complete pass handles both schemas and clears or rewrites both the caches and the references.

Charts as Part of a Coordinated Cleanup

The chart cache rarely travels alone. The same source data it freezes is usually also frozen in the pivot cache if a pivot drove the chart, preserved in the shared-strings table if the labels were ever typed into cells, and reachable through the external-links layer if the series pointed at another workbook. Stripping the chart cache while leaving those siblings populated removes one copy of the data and ships three others. A workbook is only chart-clean when the cache, the references, and every parallel store of the same numbers are handled in one pass.

The broader lesson is the one this series keeps returning to: a workbook is a package of cooperating parts, and the same data is frequently stored in several of them at once. A chart looks like the most innocent object in the file — a summary, a picture, the opposite of raw data. In the format it is one of the most faithful copies of that raw data the workbook carries, sitting in plain XML behind a layer of paint.

The Picture Was Never the Point

A chart is meant to be the safe thing to share — the distilled, rounded, presentation-ready summary you hand over precisely because it is not the underlying data. The cache quietly inverts that intention. Behind every bar is its exact value to full precision; behind every label is the verbatim text the author typed; behind the whole picture is a reference naming the sheet it came from, intact even after that sheet is deleted. None of it shows in the rendered chart, and none of it is removed by hiding the source, deleting the source, or running Document Inspector. All of it is plain UTF-8 in xl/charts/, recoverable with a ZIP reader and a ten-line script.

For workbooks that stay inside an organisation, the cache is exactly what it was built to be: the thing that makes charts fast and resilient. For workbooks crossing the perimeter, it is a full copy of the data the author thought they had left behind. The only durable defences are to flatten finished charts to pictures or to rewrite the caches and references in code — and to remember that in this format, the picture was never the point. The data behind it is.