How to Prevent Memory Leaks in JavaScript Closures

A closure keeps its outer variables alive. That is the feature. But when you hold onto a closure longer than you need to, those variables stay in memory too. That is the memory leak, and it gets worse the larger the captured data is and the longer the closure survives.

This is not a closure bug. It is the expected behavior working against you when you forget to clean up. The five patterns below cover the most common ways this happens in real applications, along with the specific fix for each one.

Leak Pattern 1: Forgotten Event Listeners

Every event listener is a closure. When the DOM element it is attached to is removed, but the listener still references something large, the memory stays allocated. The setup below allocates a large array and attaches an inline listener that closes over it:

javascript

function setupChart(container) {
  const bigData = new Array(1000000).fill(0); // Large allocation
 
  container.addEventListener("click", function() {
    console.log(bigData.length); // Closure holds bigData
  });
}

Removing the container from the page does not remove the listener attached to it. The browser cannot garbage collect the listener, and by extension bigData, until something explicitly detaches it:

javascript

document.body.removeChild(container);
// Leak: bigData is still referenced by the orphaned listener

The fix has two parts: give the listener a named reference so it can be removed later, and return a cleanup function that the caller is responsible for running. Naming the handler is what makes removeEventListener able to find and detach the exact same function:

javascript

function setupChart(container) {
  const bigData = new Array(1000000).fill(0);
 
  function handleClick() {
    console.log(bigData.length);
  }
 
  container.addEventListener("click", handleClick);
 
  return function cleanup() {
    container.removeEventListener("click", handleClick);
    // bigData can now be garbage collected
  };
}

Calling the returned cleanup function before removing the element breaks the reference chain, so bigData becomes eligible for garbage collection instead of lingering with the orphaned listener:

javascript

const cleanup = setupChart(myContainer);
 
// Later, when the container is removed:
cleanup();
document.body.removeChild(myContainer);

Leak Pattern 2: setInterval Without clearInterval

Intervals create persistent closures. If you never clear them, the closure and its variables live forever, since the interval keeps invoking the callback long after whatever started it has been forgotten:

javascript

// Leak: the interval never stops
function startPolling(url) {
  const cache = {};
 
  setInterval(async () => {
    const response = await fetch(url);
    const data = await response.json();
    cache[Date.now()] = data; // cache grows forever
  }, 5000);
}
 
startPolling("/api/status");

The fix keeps a reference to the interval ID that setInterval returns, then passes that ID to clearInterval to stop the timer permanently:

javascript

function startPolling(url) {
  const cache = {};
  const intervalId = setInterval(async () => {
    const response = await fetch(url);
    const data = await response.json();
    cache[Date.now()] = data;
  }, 5000);
 
  return function stop() {
    clearInterval(intervalId);
    // cache can now be garbage collected
  };
}

Once the caller invokes the returned stop function, the interval callback never runs again, so the closure holding cache has nothing left keeping it alive:

javascript

const stop = startPolling("/api/status");
 
// When done:
stop();

Leak Pattern 3: Closures That Capture Too Much

A closure captures the entire outer scope, not just the variables it uses. If the outer scope contains large data, the closure keeps all of it alive, even the parts the inner function never actually touches:

javascript

// Leak: processItem only needs item, but captures everything
function processLargeList(items) {
  const hugeResult = computeExpensive(items); // Large object
 
  items.forEach(function(item) {
    // This closure captures hugeResult even though it does not use it
    console.log(item.name);
  });
 
  // hugeResult stays alive as long as any callback exists
}

The fix uses a plain for-of loop instead of forEach, so there is no inline callback function at all to accidentally close over hugeResult:

javascript

function processLargeList(items) {
  const hugeResult = computeExpensive(items);
 
  // Process items without capturing hugeResult in the closure
  for (const item of items) {
    console.log(item.name);
  }
 
  // Use hugeResult here, then it can be collected
  return hugeResult.summary;
}

If you do need forEach, extract the callback into a standalone function defined outside processLargeList so it only closes over what it needs:

javascript

function logItem(item) {
  console.log(item.name); // Closes over nothing important
}
 
function processLargeList(items) {
  const hugeResult = computeExpensive(items);
  items.forEach(logItem); // No extra capture
  return hugeResult.summary;
}

Because logItem is defined outside processLargeList, it never had access to hugeResult in the first place, so there is nothing for the engine to keep alive on its behalf.

Leak Pattern 4: Accumulating Closures in Loops

Creating closures in a loop and storing them all can consume memory quickly, since each closure keeps its own captured object alive independently:

javascript

// Leak: stores 10000 closures, each with its own captured scope
const handlers = [];
for (let i = 0; i < 10000; i++) {
  const data = generateLargeObject(i);
  handlers.push(() => process(data));
}

The fix here is to notice that the closures were never actually needed. If the data can be processed immediately instead of deferred, storing 10,000 large objects and 10,000 wrapper functions was unnecessary work in the first place:

javascript

// Better: process data immediately, or use a single handler
const results = [];
for (let i = 0; i < 10000; i++) {
  results.push(process(generateLargeObject(i)));
}

Leak Pattern 5: DOM References in Closures

A closure that references a DOM element prevents both the element and the closure from being garbage collected, even after the element is removed. Attaching the handler directly onto the element, as shown below, creates a reference cycle between the two:

javascript

// Leak: circular reference between DOM and closure
function bindElement(el) {
  el.clickHandler = function() {
    console.log(el.id); // el referenced in closure
  };
  el.addEventListener("click", el.clickHandler);
}

The fix captures only the small piece of data the handler actually needs, the id string, instead of the whole element, and returns a cleanup function to break the listener reference explicitly:

javascript

function bindElement(el) {
  const id = el.id; // Capture only what you need
 
  function handleClick() {
    console.log(id); // No DOM reference in closure
  }
 
  el.addEventListener("click", handleClick);
 
  return () => el.removeEventListener("click", handleClick);
}

Neither el nor the handler function ever appear on each other as properties this time, so once the element is removed and the listener detached, both can be collected independently.

How to Detect Leaks

Fixing the five patterns above only helps once you know a leak exists. Guessing which pattern applies without evidence wastes time, so it helps to confirm the leak first. The browser's developer tools can confirm one before you go looking for the cause:

Every fix in this article follows the same underlying idea: release the reference once it is no longer needed, whether that is a listener, a timer, or a large object sitting in an unused closure. None of the fixes require a special tool, just a habit of pairing every setup with a matching teardown.

A useful habit is to ask, for every closure that outlives the function that created it, exactly what it needs to remember and nothing more. If the answer includes an entire large object, a DOM element, or an open timer, that is worth a second look before the code ships, especially in code that runs repeatedly, like a component that mounts and unmounts many times over a session.

For more on closures, see JavaScript Closures Deep Dive: Complete Guide. For real-world patterns, see Practical Use Cases for JS Closures in Real Apps.