Documentation
Learn how to analyze Chrome heap snapshots, interpret the data, and identify memory leaks in your JavaScript applications.
F12 or Cmd+Option+I).heaptimeline fileGo to the Dashboard, drag your snapshot file onto the drop zone (or click to browse), and HeapScope will analyze it instantly in your browser — no upload, no waiting.
💡 Your data never leaves your computer. Analysis happens 100% client-side.
What you're looking at: Suspected memory leak candidates, ranked by severity. HeapScope uses heuristics to detect patterns that commonly indicate leaks.
⚠️ These are heuristic detections. Not all flagged items are actual leaks — always verify by reviewing the code paths.
What you're looking at: Object allocation trends over time. Two charts show allocation rate and cumulative object count.
A bar chart showing how many new objects were created in each time window.
A line chart tracking total object count over time.
If you see a steady climb in cumulative objects with no downward drops, that's a strong leak signal. Cross-reference with the GC Health tab to confirm whether garbage collection is happening at all.
What you're looking at: Memory attributed to each JavaScript source file, based on call stacks captured during allocation.
If a script shows high "Total retained" with many objects, investigate why those objects aren't being freed. This often points to a specific library, component, or module that's holding references. Look for third-party libraries (analytics, widgets, SDKs) that may not clean up after themselves.
💡 If a script shows high "Total retained" with many objects, investigate why those objects aren't being freed.
What you're looking at: The top 20 object types by total retained heap size.
Array, HTMLDivElement)High object counts (>10k) or large average sizes may indicate bloat or improper data structures. Compare with the Type Analysis charts to see if a type has many small instances (possible accumulation) or few large instances (possible buffer leak).
⚠️ High object counts (>10k) or large average sizes may indicate bloat or improper data structures.
What you're looking at: Two visualizations showing heap composition: memory distribution by type (doughnut) and object count by type (horizontal bar).
Shows which object types consume the most total heap memory. Helps identify memory hogs.
Shows which types have the most instances. High counts may indicate accumulation or caching issues.
Compare both charts: if a type has many instances but little memory (like small strings), vs. few instances but lots of memory (like large buffers), you'll see different culprits. A type that dominates both charts is your primary target for investigation.
💡 Compare both charts: if a type has many instances but little memory (like small strings), vs. few instances but lots of memory (like large buffers), you'll see different culprits.
What you're looking at: DOM elements that have been removed from the document but are still held in memory by JavaScript references.
When you remove an element from the DOM, the browser normally garbage collects it. But if your code holds a reference to it (e.g., in a closure, global, or event listener), the browser can't free it — and it stays in memory indefinitely.
HTMLDivElement)The retainer chain traces backwards from the leaked node toward a GC root. Each arrow shows which object holds a reference, and via what property. Follow the chain to find the root cause — often a global store, event emitter, or closure that's keeping the entire subtree alive. The object at the end of the chain (marked [root]) is your cleanup target.
💡 Click on a detached node to expand its retainers and trace the reference chain — this tells you what to fix in your code.
What you're looking at: How objects are distributed across size buckets, from tiny (< 64 bytes) to huge (> 100 KB).
If the Memory chart is dominated by huge objects but the Count chart shows few of them, you have a "few big leaks" problem (e.g., unclosed WebSockets holding large buffers). If both charts show dominance in the same bucket, you have a "many small leaks" problem (e.g., accumulating event listeners or state objects).
What you're looking at: Whether garbage collection is happening during your recording, and how effective it is at reclaiming objects.
HeapScope detects GC events by looking for decreases in the cumulative object ID between timeline samples. When the browser garbage collects objects, the next sample's lastId drops because freed IDs are reused.
The cumulative objects line with red dots marking GC events. A healthy app shows steady growth with periodic drops. A leaking app shows a smooth upward curve with no drops.
⚠️ GC inference is based on object ID drops, not direct GC pause measurement. It may miss minor GCs that don't reuse IDs immediately.
At the top of Leak Detection, four cards summarize your heap:
Your app's current memory footprint. Benchmarks depend on your app, but >200 MB is usually a warning sign.
Count of heuristic detections. Zero is ideal; high counts warrant investigation.
Removed elements still in memory. Any count >0 is suspicious; >100 is a likely leak.
Allocation snapshots captured during recording. More samples = more detail on growth patterns.
Open your app, let it settle, then take a heap snapshot. Upload to HeapScope and note the Total heap size and Suspected leaks count. This is your baseline.
Do the action you suspect leaks memory: open a modal, navigate to a page, trigger a data fetch, or interact with a complex component. Then take a second snapshot.
Upload the second snapshot. Look for:
For the most suspicious leak:
Apply the fix (remove listeners, clear caches, unsubscribe, etc.), then repeat Steps 1-2. The leak should disappear or significantly reduce. Use Size Distribution to confirm the shape of the heap has changed — the problematic bucket should shrink.
💾 Best practices
Take snapshots after your app has run for several minutes — this gives leaks time to accumulate and become visible.
🔍 Investigating leaks
Start with Leak Detection → click a flagged leak → review the "Source" and "Retainers" to see where the reference is held in your code.
📊 Comparing snapshots
Take a snapshot, perform an action (e.g., open/close a modal), take another snapshot. Compare results to see what that action leaked.
🎯 Common culprits
Event listeners (remove with removeEventListener), closures (avoid capturing large objects), and timers (clear with clearInterval).
🕵️ Using retainer chains
The retainer chain traces from a leaked object back to a GC root. The object at the end of the chain (marked [root]) is your cleanup target — fix that, and everything upstream gets freed.
📉 GC Health as a leak signal
If GC Health shows "No GC detected" and the cumulative chart is a smooth upward line, you have a severe leak. If GC is active but the line still climbs, GC can't keep up — you're allocating faster than collecting.
Head to the dashboard and upload your first heap snapshot.
Open dashboard