Finding memory leaks

Prove what keeps memory in use

JavaScript keeps the objects your code makes in an area of memory called the heap. When nothing can reach an object any more, the engine frees its memory. This cleanup is called garbage collection, or GC for short. The memory management lesson explains it step by step.

A memory leak happens when your code keeps a link to an object it no longer needs. Then the engine can't free that object. If this happens again and again, the heap keeps growing.

This lesson shows how to find a leak with Chrome DevTools, the tools built into the Chrome browser. The WeakRef & FinalizationRegistry lesson showed why weak references are rarely the fix. Here you use DevTools to find which object still holds the memory.

You need this in real apps, such as:

• a single-page app that switches pages without reloading;
• a dashboard that stays open all day;
• a long list that loads more rows as you scroll;
• a pop-up window, called a modal, that opens and closes hundreds of times;
• a developer tool that keeps large amounts of loaded data.

The steps are always the same:

1. Measure the memory.
2. Pick one action to test.
3. Take heap snapshots and compare them.
4. Follow the links to the object that holds the memory.
5. Fix the code that keeps that link.
6. Compare again to check the fix.

Open Chrome DevTools and choose the Memory panel. It has several tools. Some of them talk about allocation: setting aside memory for a new object. Each tool answers a different question:

• Heap snapshot: what is in memory right now?
• Allocation instrumentation on timeline: which objects were made during this action, and are they still there at the end?
• Allocation sampling: which code makes the most objects over a long run?
• Detached elements: which removed page elements does JavaScript still hold?

The table lists these tools and two more. Read each row as: this tool records this, so use it when you need this.

A heap snapshot can be shown in four views:

• Summary groups objects by their constructor, the function that made them, such as Array or Map.
• Comparison shows how the count of each kind of object changed between two snapshots.
• Containment starts from the starting points, such as Window, and lets you open what they hold.
• Statistics shows a pie chart of what uses the memory.

The toolbar also has a button that runs garbage collection right away. It has a filter by constructor name, too, and filters such as "objects made between two snapshots" or "objects kept by detached nodes".

A heap snapshot is not a picture of all the computer's memory. It is a graph: a set of JavaScript objects and page elements, joined by links. Each link is a reference: one object points to another. Here are the words you need:

• A root is a starting point that is always kept, such as window. DevTools calls these GC roots.
• Roots point to objects, and objects point to more objects.
• A retainer is an object that keeps another object in memory by pointing to it. The Retainers pane lists every object that points to the object you selected.
• Retained size is the memory that would be freed if one object were gone. It counts the object itself, plus every object you can reach only through it.
• If every path from a root to object B goes through object A, DevTools says A dominates B. Then freeing A would free B too.

The table explains the words you read in a snapshot. Read each row as: this word means this, and you use it like this.

The next step-through uses a small, made-up heap that always gives the same result. The lesson provides four helper functions, so Edit & run works on the code exactly as shown:

• createLeakSnapshot(n) builds a made-up heap after n leaky actions.
• computeReachable lists every object the roots can reach.
• computeRetainedSizes works out the retained size of each object.
• findRetainerPath finds the shortest path from a root to one object.

1const snapshot = createLeakSnapshot(1);Run2const reachable = computeReachable(snapshot);3const retained = computeRetainedSizes(snapshot);4const path = findRetainerPath(snapshot, "button:1");5 6console.log(reachable.length);7console.log(path.join(" -> "));8console.log(retained["panel:1"]);

A reliable way to find growth is called the three-snapshot technique. Before each snapshot, press the button that runs garbage collection, so only objects that are really kept remain.

1. Load the page. Do the action once as a warm-up, so code that loads late and caches can settle. Take Snapshot 1.
2. Do the action you suspect once more. Take Snapshot 2.
3. Repeat the same action several more times. Take Snapshot 3.

Open Snapshot 3 in the Comparison view, against Snapshot 2. Each snapshot has a job:

• Snapshot 1 checks that the warm-up is done.
• Snapshot 2 is the starting point, often called the baseline, that you measure from.
• Snapshot 3 shows what grew while you repeated the action.

The change in a count between two snapshots is called the delta. A constructor row with a growing delta is a suspect, not proof. For proof, pick one object in that row. Then follow its retainers back to a root in your code.

1const before = createLeakSnapshot(1);Run2const after = createLeakSnapshot(5);3const diff = diffConstructorCounts(before, after);4const detached = diff.find((row) => row.name === "DetachedHTMLDivElement");5const functions = diff.find((row) => row.name === "Function");6console.log(detached.delta);7console.log(functions.delta);8console.log(diff.filter((row) => row.delta > 0).map((row) => row.name + ":" + row.delta).join(", "));

The step-through only shows the last part: Snapshot 2 compared with Snapshot 3. Its before heap has one action. Its after heap has five. So the difference is four extra actions, not five.

In Chrome's Summary view, the constructor filter can show Objects allocated between Snapshots 2 and 3. In the Comparison view, sort by the positive deltas, open a constructor, and pick one object. Then read the Retainers pane. The playground below shows these deltas without making the browser use real memory.

1const before = createLeakSnapshot(1);2const after = createLeakSnapshot(5);3const diff = diffConstructorCounts(before, after);4const detached = diff.find((row) => row.name === "DetachedHTMLDivElement");5const functions = diff.find((row) => row.name === "Function");6console.log(detached.delta);7console.log(functions.delta);8console.log(diff.filter((row) => row.delta > 0).map((row) => row.name + ":" + row.delta).join(", "));

A retainer chain answers one question: who still points at this object? Start at an object that should be gone. Then follow the Retainers pane, one link at a time, until you reach a root your code owns.

Chains often end at one of these:

• a Map stored in a variable at the top of a module;
• a listener on window;
• a timer callback;
• a closure;
• a cache inside a framework;
• an object you looked at in the DevTools console.

Here are four common ones, and how to fix each:

• Module cache: a Map at the top of a module stores page elements or page data. It never deletes old entries. Fix it with a size limit, or delete old entries yourself. If you only attach extra data to objects, use a WeakMap or WeakSet.
• Event listener: window or document keeps a callback, and the callback uses data from a page that is closed. Fix it with removeEventListener or an AbortController. If the listener should run only once, pass { once: true }. The events lesson explains how listeners work.
• Timer: the browser's timer list keeps a setInterval callback alive. Fix it with clearInterval or clearTimeout when the feature closes. The timers lesson explains the timer list.
• Closure: a closure is a function plus the variables it remembers from where it was made. A callback that lives a long time may remember more than it needs. Keep only an ID or a count when that is enough. The closures lesson explains them.

The DOM is the tree of elements that makes up the page. Each element in it is a node. A detached DOM node is a node that was removed from the tree, but that JavaScript still points at. So the engine can't free it.

In a snapshot, you can find detached nodes with the Detached elements tool, with the detached-node filters, or by a constructor name such as DetachedHTMLDivElement. The real clue is the retainer path: an array, a listener, a closure, a cache, or the console still points at the node.

1const retainedNodes = [];2const leakedListeners = [];3 4function mountAndLeakPanel() {5  const panel = document.createElement("section");6  panel.className = "preview-panel";7  panel.textContent = "Preview panel";8  const onResize = () => panel.textContent.length;9  window.addEventListener("resize", onResize);10  document.body.append(panel);11  panel.remove();12  retainedNodes.push(panel);13  leakedListeners.push(onResize);14}15 16mountAndLeakPanel();17console.log(document.querySelector(".preview-panel") === null);18console.log(retainedNodes.length);19console.log(retainedNodes[0].isConnected);20for (const listener of leakedListeners) window.removeEventListener("resize", listener);21retainedNodes.length = 0;

The code makes a panel, adds it to the page, and removes it. Then it prints three lines:

• true: the search for .preview-panel finds nothing, so the panel is not in the page.
• 1: the retainedNodes array still holds the panel.
• false: the panel's isConnected property is false, which means it is not attached to the page.

The last two lines clean up this demo. They remove the listeners and empty the array.

The fix uses an AbortController. It gives you a signal. Pass the signal when you add a listener. Later, call controller.abort(), and the browser removes that listener.

1const retainedNodes = [];2 3function mountAndCleanPanel() {4  const controller = new AbortController();5  const panel = document.createElement("section");6  panel.className = "preview-panel";7  panel.textContent = "Preview panel";8  const onResize = () => panel.textContent.length;9  window.addEventListener("resize", onResize, { signal: controller.signal });10  document.body.append(panel);11  panel.remove();12  controller.abort();13}14 15mountAndCleanPanel();16console.log(document.querySelector(".preview-panel") === null);17console.log(retainedNodes.length);18console.log("listener aborted");

This version prints true, 0, and listener aborted. The panel is gone from the page, the array is empty, and no listener points at the panel any more.

1const retained = [];2 3function leakyMountUnmount(host) {4  const panel = document.createElement("section");5  panel.textContent = "Preview";6  const onResize = () => panel.textContent.length;7  window.addEventListener("resize", onResize);8  host.append(panel);9  panel.remove();10  retained.push({ panel, onResize });11}12 13function fixedMountUnmount(host) {14  const controller = new AbortController();15  const panel = document.createElement("section");16  panel.textContent = "Preview";17  window.addEventListener("resize", () => panel.textContent.length, { signal: controller.signal });18  host.append(panel);19  panel.remove();20  controller.abort();21}

A heap snapshot answers: what is in memory now? The allocation tools answer: when was it made? To use Allocations on timeline:

1. Start recording.
2. Do the action.
3. Stop recording, and select a time range.

The timeline shows bars of new objects:

• Blue bars are objects still in memory at the end of the recording.
• Gray bars are objects that were made and later freed.

When you select a constructor, the Retainers pane shows what keeps its objects in memory.

Allocation sampling checks only some of the new objects, so it is less exact. In return, it slows the page down less. It also groups memory by the chain of function calls that made it. Use it for dashboards that run a long time, or for heavy actions.

For a quick trend, open Performance monitor and watch the JS heap size while you repeat the action. Or record in the Performance panel with the Memory checkbox on. Then the heap growth lines up with scripts, drawing, and events on the same timeline.

1// Chrome exposes this non-standard property in some contexts.2console.log("memory" in performance);3 4// This newer measurement requires cross-origin isolation headers.5if (crossOriginIsolated && "measureUserAgentSpecificMemory" in performance) {6  const report = await performance.measureUserAgentSpecificMemory();7  console.log(report.bytes);8} else {9  console.log("needs cross-origin isolation");10}

performance.memory is not part of any web standard. Only Chrome has it. The newer measureUserAgentSpecificMemory() needs cross-origin isolation: a security setup that the server turns on with special headers. So use these for careful checks you control. Don't build app logic that expects them in every browser.

Node.js runs JavaScript outside the browser. It uses V8, the same engine as Chrome, so heap snapshots work the same way. To look at a Node program on your own computer:

1. Start it with the --inspect flag.
2. Open chrome://inspect in Chrome.
3. Choose your Node program, and use the Memory panel.

Be careful on a live server. While Node takes a snapshot, it stops running your other code, and it may need a lot of extra memory. So keep the way to start a snapshot private, and use it only where a crash would do no harm.

node --inspect server.js
# Open chrome://inspect, choose the Node target, then use the Memory panel.

1import v8 from "node:v8";2console.log(typeof v8.getHeapStatistics);3console.log(typeof v8.writeHeapSnapshot);4console.log(v8.getHeapStatistics().heap_size_limit > 0);

In this lesson's tests on Node 22, the check prints function, function, and true. To write a real snapshot, call v8.writeHeapSnapshot() from a safe, private place in your code. Then open the .heapsnapshot file in Chrome DevTools.

1import { writeHeapSnapshot } from "node:v8";2 3// Use a private diagnostics path and protect whatever trigger calls this.4const file = writeHeapSnapshot("./diagnostics/app.heapsnapshot");5console.log(file);

Node can also write snapshots for you. The --heapsnapshot-near-heap-limit=3 flag tells it to write up to three snapshots as the heap gets close to its size limit, before an out-of-memory crash.

node --heapsnapshot-near-heap-limit=3 server.js
# Node writes up to three snapshots as the heap approaches its limit.

Hunt a leak like any other bug, with steps you can repeat. Don't guess. The advanced debugging lesson uses the same steps for breakpoints and traces: make the bug happen every time, remove other noise, look, explain, fix, and check.

1. Reproduce: Make the leak happen with the smallest action you can repeat, such as opening and closing a panel.
2. Measure: Use Performance monitor or the Memory checkbox in the Performance panel. Check whether the JS heap keeps rising after garbage collection.
3. Isolate: Turn off other work, reload, do the action once as a warm-up, then repeat only the action you suspect.
4. Compare: After the warm-up, take Snapshot 1. Do the action once and take Snapshot 2. Repeat the action, take Snapshot 3, then compare Snapshot 2 with Snapshot 3.
5. Follow retainers: Open a constructor row that grew, pick one object, and read Retainers until you reach a root you own.
6. Fix and verify: Remove listeners, abort signals, clear timers, limit caches, or use WeakMap or WeakSet when the link should not keep the object. Then compare again.

1// Run in a dedicated Node process, not in a normal browser page.2// node --expose-gc leak-regression.test.js3const registry = new FinalizationRegistry((label) => {4  console.log("collected", label);5});6 7(function mountAndUnmount() {8  const marker = { label: "panel" };9  registry.register(marker, "panel");10})();11 12globalThis.gc?.();13await new Promise((resolve) => setTimeout(resolve, 0));14console.log("test can only use this as a best-effort signal");

Common misconceptions

Each row shows a wrong idea and what is really true.

Key takeaways

• The Memory panel has heap snapshots, an allocation timeline, allocation sampling, and a detached elements tool.
• A heap snapshot is a graph of objects joined by links. Retained size counts what only one object reaches. The Retainers pane shows why an object is still in memory.
• In the three-snapshot technique, Snapshot 1 checks the warm-up, Snapshot 2 is the starting point, and Snapshot 3 shows growth from repeating the action.
• A detached DOM node leaks only while JavaScript still points at it. Follow the retainer chain to the array, listener, closure, cache, or console that holds it.
• Fix the root that holds the memory. Then run the same comparison again, and add a careful regression test.

Next, the course goes deeper into performance and how the engine works. Come back to these steps any time a page, a dashboard, or a long session keeps getting heavier.