Articles

Fix Node.js JavaScript Heap Out of Memory Error (2026)

April 18, 2026 7 min read

The Node.js JavaScript heap out of memory error means the V8 JavaScript engine ran out of room to store application data.

Here are the most common culprits and how to fix them:

1. Insufficient Heap Limit for Your Application

Your Node.js process is configured with a default heap size that’s too small for your application’s needs. This is especially common in larger applications or those handling significant data.

  • Diagnosis: Run your application and observe its memory usage. You can also check the current heap limit by setting the NODE_OPTIONS environment variable:

    NODE_OPTIONS="--trace-gc" node your_app.js

    Look for frequent garbage collection cycles and high memory usage reported by your system’s process monitor.

  • Fix: Increase the maximum heap size using the --max-old-space-size flag. For example, to set it to 4GB:

    node --max-old-space-size=4096 your_app.js

    This allocates more contiguous memory for the V8 heap, allowing your application to store more data before triggering an out-of-memory error.

  • Why it works: The V8 engine has a default maximum heap size (often around 2GB on 64-bit systems). When your application’s data exceeds this limit, it crashes. Increasing this limit provides more headroom.

2. Memory Leaks in Your Code

Your application is allocating memory but failing to release it when it’s no longer needed, leading to a gradual accumulation that eventually exhausts the heap.

  • Diagnosis: Use Node.js’s built-in profiler or external tools like heapdump to capture heap snapshots at different points in your application’s lifecycle. Compare these snapshots to identify objects that are growing in number or size unexpectedly.

    npm install heapdump

    In your code, add:

    const heapdump = require('heapdump');

// Trigger a heap dump when a certain condition is met, e.g., before a crash
// or on a specific interval.
setInterval(() => {
    heapdump.writeSnapshot();
}, 300000); // Dump every 5 minutes

    Analyze the generated .heapsnapshot files using Chrome DevTools (Memory tab). Look for detached DOM elements, large arrays, or closures that are holding onto references to objects that should have been garbage collected.

  • Fix: Identify the specific code patterns causing the leak. Common causes include:

    • Global variables: Unintentionally declared global variables persist until the process ends.
    • Event listeners: Forgetting to remove event listeners when an object is no longer needed.
    • Timers: setInterval or setTimeout callbacks that maintain references to objects.
    • Closures: Closures that inadvertently keep references to large objects alive. For example, if you have a listener that’s never removed:
    // Leaky code:
const largeData = new Array(1000000).fill('x');
const leakyObject = {
    data: largeData,
    process: () => {
        // ... do something
    }
};
// Event listener that keeps leakyObject alive indefinitely
someEventEmitter.on('event', () => {
    leakyObject.process();
});

// Corrected code:
const largeData = new Array(1000000).fill('x');
const leakyObject = {
    data: largeData,
    process: () => {
        // ... do something
    }
};
const handler = () => {
    leakyObject.process();
};
someEventEmitter.on('event', handler);

// Later, when leakyObject is no longer needed:
someEventEmitter.removeListener('event', handler);

    By removing unnecessary references (like the event listener in the example), you allow the garbage collector to reclaim the memory.

  • Why it works: Memory leaks prevent the garbage collector from freeing up unused memory. By identifying and fixing the code that holds onto these references, you enable the GC to do its job and prevent memory from accumulating indefinitely.

3. Processing Large Data Sets Without Streaming

Your application attempts to load entire large files or database query results into memory at once, rather than processing them in smaller, manageable chunks.

  • Diagnosis: This often manifests when performing operations like reading a very large CSV file, fetching thousands of records from a database, or processing large JSON payloads. Use your system’s tools (top, htop, Activity Monitor) to see if memory usage spikes dramatically during these specific operations.

  • Fix: Implement streaming for I/O operations. For file reading:

    const fs = require('fs');
const readline = require('readline');

async function processLargeFile(filePath) {
    const fileStream = fs.createReadStream(filePath);
    const rl = readline.createInterface({
        input: fileStream,
        crlfDelay: Infinity // To handle all instances of CR LF
    });

    for await (const line of rl) {
        // Process each line here. Memory usage remains low.
        console.log(`Line from file: ${line}`);
    }
    console.log('Finished processing file.');
}

processLargeFile('large_data.txt');

    For database operations, use database drivers that support cursor-based or stream-based fetching of results, rather than toArray() or fetchall().

  • Why it works: Streaming reads data piece by piece. Instead of holding the entire dataset in memory, you process each chunk as it arrives, drastically reducing the peak memory requirement.

4. Inefficient Data Structures or Algorithms

Your application uses data structures (like massive arrays or objects) or algorithms that are inherently memory-intensive for the task at hand.

  • Diagnosis: This is harder to diagnose directly with a single command. It requires code review and profiling. Look for:

    • Storing entire datasets in JavaScript arrays or objects where a more efficient representation might exist.
    • Algorithms that generate large intermediate data structures.
    • Frequent creation and destruction of large objects.

  • Fix: Refactor your code to use more memory-efficient data structures. For example:

    • If you’re storing a large number of boolean flags, consider using a Uint8Array or bit manipulation instead of an array of true/false strings or booleans.
    • If you need fast lookups but the data is sparse, a Map might be more memory-efficient than a large object if keys are non-string.
    • For numerical data, consider typed arrays (Int32Array, Float64Array, etc.). For instance, instead of:
    // Inefficient: Array of strings representing numbers
const data = ['1', '2', '3', /* ... 1 million more */];

    Use:

    // Efficient: Typed array of numbers
const data = new Float64Array(1000000); // Or Int32Array, etc.
// Populate data...

  • Why it works: Different data structures have different memory footprints. Typed arrays, for example, store numbers more compactly than generic JavaScript arrays which store pointers to objects. Choosing the right structure can significantly reduce memory overhead.

5. Excessive Use of Buffers

When working with binary data (network requests, file I/O, crypto), Node.js uses Buffer objects. Creating and holding onto too many large buffers can exhaust memory.

  • Diagnosis: Similar to general memory leaks, use heap snapshots to look for an unusually high number of Buffer objects or large contiguous blocks of memory being held by buffers.

  • Fix: Ensure buffers are released when no longer needed. If you’re concatenating many small buffers, consider if there’s a more efficient way, or if you can process them incrementally.

    // Example of potential issue: accumulating many small buffers
let allData = Buffer.from('');
for (let i = 0; i < 10000; i++) {
    const chunk = Buffer.from(`data_chunk_${i}`);
    allData = Buffer.concat([allData, chunk]); // This creates a new, larger buffer each time
}
// allData can become very large

// Better approach if processing incrementally:
const stream = fs.createWriteStream('output.bin');
for (let i = 0; i < 10000; i++) {
    const chunk = Buffer.from(`data_chunk_${i}`);
    stream.write(chunk); // Writes to file, releasing buffer memory sooner
}
stream.end();

  • Why it works: Buffer.concat can be an expensive operation as it creates a new, larger buffer and copies data from the old ones. Processing or writing data in chunks as it’s received or generated avoids accumulating large, monolithic buffers.

6. Third-Party Module Issues

Sometimes, the memory leak or excessive memory consumption isn’t in your code directly, but within a dependency you’re using.

  • Diagnosis: Use heap profiling as described in point 2, but focus your analysis on the objects and code originating from your node_modules directory. Tools like npm ls or yarn list can help you identify which dependencies are being used.

  • Fix:

    • Update the module: Check if there’s a newer version of the problematic dependency that has fixed the memory issue.
    • Report the bug: If it’s a confirmed bug, open an issue on the module’s GitHub repository.
    • Find an alternative: If the issue is severe and unaddressed, you might need to find a different library that performs a similar function.
    • Workaround: Sometimes, you can work around the issue by using the module in a specific way that avoids the leaky path, or by restarting the Node.js process periodically if a leak is unavoidable.

  • Why it works: By updating or replacing the faulty module, you’re using code that correctly manages its memory, thereby resolving the issue without needing to rewrite your application’s core logic.

After fixing these, you might encounter RangeError: Maximum call stack size exceeded if your recursion or deep function calls are now able to run further before hitting a different limit.

Want structured learning?

Take the full Nodejs course →