Forgotten event listeners, closures holding references, detached DOM nodes, timer leaks — most JavaScript memory leaks are completely avoidable. Here’s how to find them, fix them, and write code that doesn’t create them in the first place.
Memory leaks are the slow death of JavaScript applications. They don’t crash your app. They don’t throw errors. They don’t log warnings. They quietly accumulate — page gets sluggish after 30 minutes, browser tab grows from 50MB to 800MB, users restart the browser without knowing why. By the time someone notices, the trail is cold.
Most memory leaks in JavaScript are not mysterious. They fall into a small number of well-understood patterns. Once you can identify those patterns, you can find leaks in minutes with Chrome DevTools and fix them with changes that are often a single line.
This post covers the full picture: what causes memory leaks, how to find them with DevTools, how to fix every category of leak, and the coding patterns that prevent them from appearing in the first place.
How JavaScript Memory Works (Just Enough to Matter)
JavaScript manages memory automatically through garbage collection. The garbage collector (GC) periodically identifies objects that are no longer reachable from any root (the global object, the call stack, or active closures) and frees their memory.
The key word is reachable. An object is not collected as long as something holds a reference to it — regardless of whether that reference is intentional or useful.
// This object WILL be collected — nothing holds a reference after the function returns
function createTemp() {
const data = { value: 42 }
return data.value // data becomes unreachable
}
// This object will NOT be collected — the closure holds a reference indefinitely
function createLeak() {
const data = { largeArray: new Array(1_000_000).fill(0) }
return function() {
return data.largeArray.length // closure keeps data alive forever
}
}
const fn = createLeak()
// fn holds data alive. As long as fn exists, data is not collected.
A memory leak occurs when an object remains reachable — through a reference that was forgotten or not cleaned up — after it’s no longer needed. The garbage collector can’t free what it can’t see as garbage.
The Six Root Causes of JavaScript Memory Leaks
1. Forgotten Event Listeners
The most common source of leaks. When you add an event listener to a DOM element, the listener holds a reference to its callback. If that callback closes over other objects (components, data, services), those objects stay alive too.
// ✗ The leak — listener never removed
class DataDashboard {
constructor() {
this.largeDataset = new Array(100_000).fill({ value: Math.random() })
this.updateHandler = this.handleUpdate.bind(this)
// This creates a reference from window → DataDashboard instance
window.addEventListener('resize', this.updateHandler)
window.addEventListener('keydown', this.updateHandler)
document.addEventListener('scroll', this.updateHandler)
}
handleUpdate() {
// uses this.largeDataset
}
// No cleanup — when the component is removed, the listeners remain
// window still holds DataDashboard alive → largeDataset never collected
}
// ✓ Fixed — cleanup method that removes all listeners
class DataDashboard {
constructor() {
this.largeDataset = new Array(100_000).fill({ value: Math.random() })
this.updateHandler = this.handleUpdate.bind(this)
window.addEventListener('resize', this.updateHandler)
window.addEventListener('keydown', this.updateHandler)
document.addEventListener('scroll', this.updateHandler)
}
handleUpdate() {
// uses this.largeDataset
}
destroy() {
// Mirror every addEventListener with a matching removeEventListener
window.removeEventListener('resize', this.updateHandler)
window.removeEventListener('keydown', this.updateHandler)
document.removeEventListener('scroll', this.updateHandler)
this.largeDataset = null // release the reference explicitly
}
}
The critical detail: removeEventListener requires the same function reference as addEventListener. This is why this.updateHandler = this.handleUpdate.bind(this) stores the bound function — so the same reference can be removed later. Using an arrow function inline creates a new function reference that can never be matched for removal.
// ✗ Cannot be removed — new function reference each time
window.addEventListener('resize', () => this.handleUpdate())
// ✓ Can be removed — stored reference
this.handler = () => this.handleUpdate()
window.addEventListener('resize', this.handler)
window.removeEventListener('resize', this.handler)
2. Timers That Are Never Cleared
setInterval and long-lived setTimeout callbacks hold references to everything in their closure. If the component or class they belong to is destroyed without clearing the timer, the timer — and everything it references — lives on.
// ✗ setInterval that outlives the component
class LiveFeed {
constructor(feedElement) {
this.feedElement = feedElement
this.data = []
// This interval fires every second, holding feedElement and data alive
setInterval(() => {
this.fetchLatest().then(items => {
this.data = items
this.render()
})
}, 1000)
// No intervalId stored → impossible to clear → lives until page refresh
}
}
const feed = new LiveFeed(document.getElementById('feed'))
document.getElementById('feed').remove() // element removed from DOM
// But LiveFeed instance lives on — the interval still fires every second
// ✓ Timer stored and cleared in cleanup
class LiveFeed {
constructor(feedElement) {
this.feedElement = feedElement
this.data = []
this.intervalId = null
}
start() {
this.intervalId = setInterval(() => {
this.fetchLatest().then(items => {
this.data = items
this.render()
})
}, 1000)
}
destroy() {
if (this.intervalId !== null) {
clearInterval(this.intervalId)
this.intervalId = null
}
this.feedElement = null
this.data = []
}
}
3. Closures Holding Unintended References
Closures are one of JavaScript’s most powerful features — and one of the most common sources of memory leaks. A closure captures the variables in its surrounding scope. If those variables hold large objects, those objects stay alive as long as the closure exists.
// ✗ Closure keeping a large object alive longer than necessary
function setupSearch(config) {
// config contains large dataset, complex metadata, full index
// config.searchIndex = 50MB of data
const processResults = function(query) {
return config.searchIndex.query(query)
// config is captured — even if we only need config.searchIndex
// the entire config object stays alive
}
return processResults
}
const search = setupSearch(largeConfig)
// largeConfig cannot be GC'd — search holds the entire config via closure
// ✓ Extract only what you need — release the rest
function setupSearch(config) {
// Extract only the specific thing needed
const searchIndex = config.searchIndex
// config itself is no longer referenced by the closure
const processResults = function(query) {
return searchIndex.query(query)
// Only searchIndex is captured — config can be GC'd
}
return processResults
}
4. Detached DOM Nodes
A detached DOM node is a node that has been removed from the document but is still referenced by JavaScript. The GC cannot collect it because JavaScript still holds a reference, even though the user can’t see it.
// ✗ DOM node kept alive after being removed from the document
const cache = new Map()
function createTooltip(content) {
const tooltip = document.createElement('div')
tooltip.className = 'tooltip'
tooltip.textContent = content
document.body.appendChild(tooltip)
// Cache the element for reuse
cache.set(content, tooltip)
return tooltip
}
function removeTooltip(content) {
const tooltip = cache.get(content)
if (tooltip) {
tooltip.remove() // removed from DOM, but cache still holds reference
// cache.delete(content) — never called → tooltip is a detached node
}
}
// ✓ Delete the reference when the node is removed
function removeTooltip(content) {
const tooltip = cache.get(content)
if (tooltip) {
tooltip.remove()
cache.delete(content) // release the reference → node can be GC'd
}
}
5. Global Variables
Variables accidentally assigned to the global scope persist for the lifetime of the page. This is particularly common in non-strict-mode JavaScript where typos create global variables.
// ✗ Accidental global — typo in variable declaration
function processData(input) {
processedData = transform(input) // no 'const', 'let', or 'var' — creates window.processedData!
return processedData
}
// window.processedData now exists and holds the processed data indefinitely
// ✓ Always use 'const' or 'let' — and enable strict mode
'use strict'
function processData(input) {
const processedData = transform(input) // local scope, collected when function returns
return processedData
}
6. WeakMap and WeakSet — The Tools JavaScript Gives You
For caches and metadata attached to objects where you don’t want to prevent GC, use WeakMap or WeakSet. These hold weak references — the GC can collect an entry if the key has no other references.
// ✗ Regular Map prevents GC — DOM nodes can't be collected
const elementMetadata = new Map()
function trackElement(element) {
elementMetadata.set(element, { clickCount: 0, lastSeen: Date.now() })
}
// When the element is removed from the DOM and JavaScript code drops its reference,
// it STILL can't be GC'd because elementMetadata holds a strong reference
// ✓ WeakMap — element can be GC'd when nothing else references it
const elementMetadata = new WeakMap()
function trackElement(element) {
elementMetadata.set(element, { clickCount: 0, lastSeen: Date.now() })
}
// When element is removed from DOM and code drops the reference,
// GC can collect it — WeakMap doesn't prevent collection
// The WeakMap entry disappears automatically
Finding Memory Leaks with Chrome DevTools
Step 1: Record a Memory Timeline
- Open DevTools → Memory tab
- Select Heap snapshot and click Take snapshot (baseline)
- Perform the action you suspect leaks (navigate to a page, open/close a modal, run a user flow)
- Click Collect garbage (the bin icon) to force GC
- Take a second snapshot
- In the dropdown, select Comparison — this shows what was allocated between snapshots but not collected
Objects added between snapshots that weren't collected = potential leaks
Look for:
- Unexpected
Detached HTMLDivElementorDetached HTMLInputElemententries - Large arrays that shouldn’t exist at this point in the application
- Component instances that should have been destroyed
Step 2: The Allocation Timeline
- DevTools → Memory → Allocation instrumentation on timeline
- Click Start
- Interact with the application normally — open/close modals, navigate routes, run the suspected operation repeatedly
- Click Stop
The timeline shows allocation bars. Bars that remain after GC (blue bars that don’t disappear) represent objects that couldn’t be collected. Click any bar to see what was allocated and the stack trace that created it.
Step 3: The Allocation Sampling Profile
For apps where you suspect a slow continuous leak (memory grows over time without a discrete cause):
- DevTools → Memory → Allocation sampling
- Click Start
- Use the app normally for 2–3 minutes
- Click Stop
This shows which functions are allocating the most memory over time, ranked by allocation size. The functions at the top of the list are where leaks are most likely to originate.
The Task Manager Trick (Quick Sanity Check)
Before diving into heap snapshots, use the browser’s built-in task manager for a quick check:
Chrome: Shift + Esc → Task Manager
Firefox: About:processes
Sort by JavaScript Memory and watch the column while you interact with the app. If JavaScript memory grows continuously and never decreases — even after navigating back to the same page — you have a leak.
Framework-Specific Leaks
React: useEffect Without Cleanup
// ✗ Effect with subscription, no cleanup — leak on unmount
function OrderTracker({ orderId }) {
const [status, setStatus] = useState(null)
useEffect(() => {
const subscription = orderService.subscribe(orderId, (newStatus) => {
setStatus(newStatus) // called even after component unmounts → React warning + leak
})
// No return → subscription never cancelled
}, [orderId])
return <div>{status}</div>
}
// ✓ Return cleanup function — React calls it on unmount and before re-running the effect
function OrderTracker({ orderId }) {
const [status, setStatus] = useState(null)
useEffect(() => {
let isMounted = true // guard against setting state on unmounted component
const subscription = orderService.subscribe(orderId, (newStatus) => {
if (isMounted) setStatus(newStatus)
})
return () => {
isMounted = false
subscription.unsubscribe() // cleanup on unmount
}
}, [orderId])
return <div>{status}</div>
}
React: Event Listeners in useEffect
// ✗ Event listener added, never removed
function KeyboardShortcuts() {
useEffect(() => {
const handler = (e) => {
if (e.key === 'Escape') closeModal()
}
window.addEventListener('keydown', handler)
// No cleanup — handler is added on every mount, never removed
}, [])
}
// ✓ Return the cleanup
function KeyboardShortcuts() {
useEffect(() => {
const handler = (e) => {
if (e.key === 'Escape') closeModal()
}
window.addEventListener('keydown', handler)
return () => window.removeEventListener('keydown', handler)
}, [])
}
Vue: Missing onUnmounted Cleanup
// ✗ Vue composable that adds listeners but never removes them
export function useWindowSize() {
const width = ref(window.innerWidth)
const height = ref(window.innerHeight)
const handler = () => {
width.value = window.innerWidth
height.value = window.innerHeight
}
onMounted(() => {
window.addEventListener('resize', handler)
// No onUnmounted → handler accumulates on every component mount
})
return { width, height }
}
// ✓ Always pair onMounted with onUnmounted
export function useWindowSize() {
const width = ref(window.innerWidth)
const height = ref(window.innerHeight)
const handler = () => {
width.value = window.innerWidth
height.value = window.innerHeight
}
onMounted(() => window.addEventListener('resize', handler))
onUnmounted(() => window.removeEventListener('resize', handler))
return { width, height }
}
Vue: watchEffect Without Cleanup
// ✗ watchEffect with an async operation — no abort on re-run
watchEffect(async () => {
const data = await fetch(`/api/users/${userId.value}`).then(r => r.json())
user.value = data
// If userId changes before this fetch completes, both fetches run
// The stale response may overwrite the fresh one
})
// ✓ Use onCleanup to abort stale requests
watchEffect(async (onCleanup) => {
const controller = new AbortController()
onCleanup(() => controller.abort()) // abort on re-run or unmount
try {
const data = await fetch(`/api/users/${userId.value}`, {
signal: controller.signal,
}).then(r => r.json())
user.value = data
} catch (err) {
if (err.name !== 'AbortError') throw err
}
})
The AbortController Pattern: Cancel Everything
AbortController is not just for fetch — it can be used to cancel any async operation that accepts a signal, including event listeners (via the signal option) and custom async logic.
// AbortController for event listeners — elegant cleanup
class ComponentManager {
constructor() {
this.abortController = new AbortController()
const { signal } = this.abortController
// signal option automatically removes listener on abort
window.addEventListener('resize', this.onResize.bind(this), { signal })
window.addEventListener('keydown', this.onKeydown.bind(this), { signal })
document.addEventListener('click', this.onClick.bind(this), { signal })
// No need to store individual handler references
// No need for individual removeEventListener calls
}
destroy() {
this.abortController.abort()
// All three listeners removed in one call
}
}
This pattern eliminates the need to store and manage individual handler references — the signal option handles everything.
Practical Leak Prevention Patterns
Pattern 1: The Cleanup Registry
For components with many listeners and subscriptions, a cleanup registry makes teardown systematic:
class CleanupRegistry {
private cleanups: (() => void)[] = []
add(cleanup: () => void): void {
this.cleanups.push(cleanup)
}
addListener(
target: EventTarget,
event: string,
handler: EventListenerOrEventListenerObject,
options?: AddEventListenerOptions
): void {
target.addEventListener(event, handler, options)
this.add(() => target.removeEventListener(event, handler, options))
}
addInterval(callback: () => void, ms: number): void {
const id = setInterval(callback, ms)
this.add(() => clearInterval(id))
}
addTimeout(callback: () => void, ms: number): void {
const id = setTimeout(callback, ms)
this.add(() => clearTimeout(id))
}
destroy(): void {
this.cleanups.forEach(fn => fn())
this.cleanups = []
}
}
// Usage
class Dashboard {
private registry = new CleanupRegistry()
constructor() {
this.registry.addListener(window, 'resize', this.onResize.bind(this))
this.registry.addListener(document, 'keydown', this.onKey.bind(this))
this.registry.addInterval(this.poll.bind(this), 5000)
}
destroy() {
this.registry.destroy() // one call cleans everything up
}
}
Pattern 2: FinalizationRegistry — Detect Leaks in Development
FinalizationRegistry runs a callback when an object is garbage-collected. This is a development tool — you can use it to verify that objects you expect to be collected actually are:
// development only — verify that components are GC'd after unmount
const leakDetector = new FinalizationRegistry((name) => {
console.log(`✓ ${name} was garbage collected`)
})
// In your component constructor or framework hook:
function createComponent(name) {
const component = {}
// Register for GC notification — the registry holds a WEAK reference
leakDetector.register(component, name)
return component
}
// If you never see "✓ MyComponent was garbage collected" after unmounting,
// you have a leak — something is still holding a reference
Pattern 3: Development-Mode Memory Assertions
// In development, assert that objects are deallocated after certain operations
async function withMemoryAssert(label, operation) {
if (process.env.NODE_ENV !== 'development') {
return operation()
}
const before = performance.memory?.usedJSHeapSize ?? 0
const result = await operation()
// Force GC if possible (only works in some environments)
if (globalThis.gc) globalThis.gc()
const after = performance.memory?.usedJSHeapSize ?? 0
const delta = after - before
if (delta > 1_000_000) { // warn if > 1MB growth
console.warn(`[Memory] ${label}: +${(delta / 1024 / 1024).toFixed(2)}MB after operation`)
}
return result
}
The Memory Leak Prevention Checklist
For every class or component:
✓ Every addEventListener has a matching removeEventListener
✓ Handler references are stored (never use inline arrow functions for listeners you need to remove)
✓ Every setInterval/setTimeout that runs continuously has a corresponding clearInterval/clearTimeout
✓ Cleanup is called in destroy() / componentWillUnmount / onUnmounted
✓ DOM references are set to null after the element is removed
✓ Cached values use WeakMap/WeakSet when keys are DOM elements or objects
✓ Closures don't capture large objects they don't need — extract only required properties
✓ AbortController used for fetch and for batching listener cleanup
For frameworks:
React:
✓ Every useEffect that adds a listener/subscription returns a cleanup function
✓ Async effects use isMounted guard or AbortController
✓ useRef used for values that shouldn't trigger re-renders (prevents stale closures)
Vue:
✓ Every onMounted listener registration has a corresponding onUnmounted removal
✓ watchEffect async operations use onCleanup with AbortController
✓ Composables that add to window/document always clean up in onUnmounted
For regular audits:
✓ Chrome Task Manager checked for continuous memory growth on key user flows
✓ Heap snapshot comparison taken before/after suspected leak operations
✓ Allocation timeline run for slow continuous leaks
✓ "Detached HTMLElement" in heap snapshots investigated and resolved
Final Thoughts
Memory leaks are entirely avoidable. They follow predictable patterns: an event listener without a removal, a timer without a clear, a closure that captured more than it needed, a DOM node reference that outlived the node. Each pattern has a mechanical fix.
The discipline that prevents leaks is simpler than debugging them: every addEventListener gets a removeEventListener. Every setInterval gets a clearInterval. Every async effect gets a cleanup. Every DOM reference gets nulled when the DOM is gone.
Browser DevTools makes finding existing leaks straightforward — a heap snapshot comparison shows you exactly which objects are alive that shouldn’t be, and the allocation timeline shows you which functions are creating them. The tools are excellent. The failure mode is not using them until the tab is consuming 800MB.
Build the cleanup habit first. Run DevTools Memory audits second. Fix what you find. The memory tab is not an advanced feature — it’s a first-line tool for any application that runs for more than a few minutes.