Back to blog

How to Find and Fix Memory Leaks in JavaScript Applications: Chrome DevTools Guide

Modern JavaScript runtimes utilize automated garbage collection, freeing developers from manual memory management. However, automated garbage collection is not magic. It only reclaims memory that it determines is unreachable.

If your code holds onto references of objects that are no longer needed, the garbage collector cannot free that memory. Over time, this leads to Memory Leaks, causing your application to slow down, lag, and eventually crash the browser tab (often with a "page unresponsive" error).

In this guide, we will look at how JavaScript handles memory, explore common sources of memory leaks, and learn how to use Chrome DevTools to locate and fix leaks.

How JavaScript Manages Memory: Mark and Sweep

Most modern JavaScript engines use the Mark and Sweep garbage collection algorithm.

The execution environment defines a set of roots (such as the global window object in the browser). The garbage collector periodically starts from these roots, finds all objects referenced by them, then recursively traverses those child objects to mark them as "active".

Any memory segment that is not reachable from the roots is swept and reclaimed. Memory leaks occur when you accidentally retain reference pathways from a root to objects you no longer need.

Common Causes of JavaScript Memory Leaks

1. Forgotten Timers and Callbacks

If you register an interval timer inside a component but forget to clear it when the component unmounts, the callback remains active. Because the callback function references variables in its scope, those variables cannot be garbage collected.

// A component mounts and sets a timer
function startTracking() {
  const largeData = new Array(1000000).fill('data');
  
  setInterval(() => {
    // This interval keeps referencing largeData
    console.log('Tracking tick...');
  }, 1000);
}

If the tracking logic is re-run multiple times, new intervals are created while old ones remain running in the background, leaking memory continuously.

2. Closures Holding Onto Scope

Closures are functions that retain access to their lexical scope. If a closure references a large variable, and that closure is kept alive (e.g., inside an event handler), the variable stays in memory.

let leakHandler;

function setupLeak() {
  const heavyData = new Array(1000000).fill('leak');
  
  leakHandler = function() {
    console.log(heavyData.length);
  };
}

Because leakHandler is a global variable, the closure remains active, and the heavyData array cannot be collected.

3. Detached DOM Nodes

A detached DOM node occurs when a node has been removed from the page, but JavaScript still retains a reference to it in an object or variable. The node cannot be collected because the GC root still references it.

let savedButton;

function removeButton() {
  const btn = document.getElementById('my-button');
  savedButton = btn; // Reference retained
  document.body.removeChild(btn); // Removed from DOM but remains in memory
}

To clean this up, set savedButton = null once the DOM removal completes.

Locating Leaks with Chrome DevTools Memory Panel

Chrome DevTools includes a powerful Memory tab to inspect heap allocation.

Step 1: Record a Heap Snapshot

  1. Open Chrome DevTools (F12) and select the Memory tab.
  2. Select Heap snapshot and click Take snapshot.
  3. Perform the actions in your app that you suspect are leaking memory (e.g., opening and closing a modal ten times).
  4. Take a second snapshot.

Step 2: Compare Snapshots

Change the perspective filter at the top from Summary to Comparison. Select Snapshot 2 and compare it against Snapshot 1.

Look for constructor names like HTMLDivElement or Closure that show a positive delta value. If you open a modal and close it, the delta for its elements should be zero. A positive delta indicates elements are retained in memory.

Step 3: Inspect Retainers

Select a leaked object in the comparison panel. The bottom Retainers panel displays the reference chain keeping the object alive. Follow the path upwards to find the specific JavaScript variable, closure, or event listener keeping the memory locked.

Conclusion

Preventing JavaScript memory leaks requires coding discipline. Always clear your timers (clearInterval), unbind global event listeners when components unmount, and set detached DOM references to null. Incorporating regular Heap Snapshot reviews into your testing pipeline helps catch memory bloat early, ensuring your applications remain fast and stable for long-running user sessions.