Quick Answer
"There isn't enough memory to complete this action" means Excel's process has run out of addressable memory. In 32-bit Excel, the entire Excel process is capped at approximately 2GB of virtual address space regardless of installed RAM. In 64-bit Excel, available system RAM is the constraint.
The fix depends on the trigger. A pivot crash needs a different fix than a sort crash or a save failure. The table below maps each trigger to its resolution.
Fast Fix (90 Seconds)
If the error just appeared, try these steps in order before anything else:
- Save what you have — if the file is still open, Ctrl+S immediately
- Close all other open workbooks — each consumes virtual address space
- Close all other applications — browsers, Slack, email are all competing for RAM
- Clear the clipboard — Home → Clipboard → Clear All (clipboard cache consumes memory)
- Retry the operation — if it succeeds, the problem was competing applications
If the error returns: You need one of the targeted fixes below based on what triggered it.
TL;DR: Excel's memory error has six distinct triggers. Most are fixed by clearing competing memory consumers, switching from 32-bit to 64-bit Excel, or reducing the size of the operation that caused the crash. When the workbook is too large for any fix, processing it outside Excel — in the browser with no memory ceiling — is the fastest path. Excel Splitter → handles files that exceed Excel's limits with no upload required.
Part of the SplitForge Excel Failure System: You're here → Excel Not Enough Memory Fix All Excel limits → Excel Limits Complete Reference Slow before crash → Excel Running Slow on Large Files Crashes on open → Excel Crashes When Opening All error messages → All Excel Error Messages Explained
Check your Excel version in 5 seconds — this determines everything: File → Account → About Excel The version string shows "32-bit" or "64-bit" in parentheses. If it says 32-bit: the fix is upgrading to 64-bit. Every other fix is a workaround.
Why Excel runs out of memory — the mental model:
32-bit Excel memory reality:
┌─────────────────────────────────────────────┐
│ Your machine RAM: 16GB │
│ Excel process sees: ~2GB MAX │
│ ────────────────────────────────────────── │
│ Open workbook: 800MB │
│ Pivot cache: 600MB │
│ Undo history: 300MB │
│ Formula cache: 200MB │
│ Clipboard + add-ins: 150MB │
│ ────── │
│ Total: 2,050MB ← CRASH │
│ │
│ Free physical RAM on same machine: 14GB │
│ Completely irrelevant to 32-bit Excel. │
└─────────────────────────────────────────────┘
64-bit Excel memory reality:
┌─────────────────────────────────────────────┐
│ Your machine RAM: 16GB │
│ Excel process can use: up to ~16GB │
│ ────────────────────────────────────────── │
│ Same 800MB workbook + all operations: │
│ Typically 3-5GB peak — no crash │
│ │
│ Memory error still possible on 64-bit │
│ when dataset genuinely exceeds system RAM │
└─────────────────────────────────────────────┘
Excel's memory error is one of the most frustrating because the fix is never the same twice. A pivot on a 400K-row file crashes, but a sort on a 2M-row file works. A save fails on a 180MB workbook, but opens on a 600MB one. The reason is that the error is not about file size — it is about the memory consumed by the specific operation at the moment it runs.
Each trigger scenario in this post was reproduced using Microsoft 365 Excel (64-bit) and Microsoft 365 Excel (32-bit), Windows 11, March 2026.
What Excel's Memory Error Messages Actually Mean
❌ PRIMARY MEMORY ERROR:
"There isn't enough memory to complete this action.
Try using less data or closing other applications.
To increase memory availability, consider:
Using a 64-bit version of Microsoft Excel.
Adding memory to your device."
❌ FORMULA/RESOURCE VARIANT:
"Excel ran out of resources while attempting to calculate
one or more formulas. As a result, these formulas cannot
be evaluated."
❌ OPEN FAILURE VARIANT:
"There is not enough memory or disk space to run Microsoft Excel."
(Appears before Excel opens — usually an add-in or temp file issue)
All three share a root cause: the Excel process has consumed available memory. The third variant is an edge case caused by corrupted temp files or conflicting add-ins rather than the workbook itself.
Quick mitigation by trigger — match your scenario and jump directly to the fix:
| Trigger | Operation that crashed | Quickest mitigation |
|---|---|---|
| Pivot table crashes | Pivot cache loading full source range | Set "Retain items per field: None" + reduce source range to actual data rows |
| Formula recalculation crash | Volatile formulas evaluating entire workbook | Formulas → Calculation Options → Manual; restrict SUMPRODUCT ranges |
| Sort or filter hangs | Sort loading full range twice in memory | Filter to relevant rows first; sort on named table range not full columns |
| Save fails | Serializing workbook + undo history | Close and reopen file (clears undo stack); strip pivot caches before saving |
| Excel won't open | Add-in or corrupted temp file consuming launch memory | Launch with /safe flag; clear %temp%; disable COM add-ins |
| Memory error on 64-bit with 16GB+ RAM | Dataset genuinely exceeds available RAM | Excel is the wrong tool for this file — process outside the grid |
Table of Contents
- Why Excel Runs Out of Memory
- Cause and Fix Table
- Fix 1: 32-Bit Excel Is the Problem
- Fix 2: Pivot Table Memory Crash
- Fix 3: Formula Recalculation Crash
- Fix 4: Sort or Filter Crash
- Fix 5: Save Failure
- Fix 6: Open Failure Before Excel Loads
- When the File Is Simply Too Large for Excel
- Additional Resources
- FAQ
This guide is for: Anyone hitting Excel's memory error on a machine that has plenty of RAM, finance teams whose pivot tables crash on large models, data analysts whose saves fail on large workbooks.
Why Excel Runs Out of Memory
Excel's process must hold the active workbook, formula caches, pivot caches, undo history, clipboard contents, and all loaded add-ins in a single memory space. The problem is not always the workbook size — it is the total memory footprint of the operation in progress.
In 32-bit Excel, this entire process is bounded by approximately 2GB of virtual address space. A machine with 32GB of installed RAM is irrelevant — the 32-bit process cannot access more than ~2GB regardless. This is the most common root cause of persistent memory errors in enterprise environments where 64-bit Excel was never deployed.
In 64-bit Excel, available system RAM is the constraint. A 64-bit process can access far more memory, but operations that load large datasets entirely into memory — full-table pivots, sorts on million-row ranges, array formula recalculations — can still exhaust even 16GB or 32GB of RAM.
❌ REAL-WORLD FAILURE — 32-bit Excel on 16GB machine:
File: quarterly_actuals_combined.xlsx (247MB)
Excel version: Microsoft 365, 32-bit, Windows 11
Available RAM: 16GB installed
Action: Create pivot table across all 623,000 rows
Memory at crash: 1.97GB / ~2GB (virtual address space exhausted)
Rows processed before crash: 623,000 attempted / 623,000 rows
Excel's 32-bit process could not allocate memory for the pivot index
despite 14GB of free physical RAM remaining on the machine.
Cause and Fix Table
| Trigger | Root Cause | Fix |
|---|---|---|
| Pivot table creation crashes | Full dataset loaded into pivot cache simultaneously | Pre-filter data before pivoting; switch to Power Query |
| Formula recalculation hangs or crashes | Volatile formulas or large SUMPRODUCT across full columns | Restrict formula ranges to data range; replace volatile formulas |
| Sort or filter crashes | Full range loaded into memory for sort operation | Split file; sort on smaller chunks |
| Save fails with memory error | 32-bit process exhausted during save (includes undo history) | Clear undo history; switch to 64-bit; split workbook |
| Excel won't open (before workbook loads) | Corrupted temp files or conflicting add-ins consuming launch memory | Clear temp files; disable add-ins; repair Office installation |
| Memory error recurs on 64-bit Excel | Dataset genuinely too large for available system RAM | Split file; process outside Excel |
Fix 1: 32-Bit Excel Is the Problem
Check your Excel version first. File → Account → About Excel. The version string includes "32-bit" or "64-bit."
If you are on 32-bit Excel and have persistent memory errors, upgrading to 64-bit is the highest-value fix — it effectively removes the ~2GB ceiling and replaces it with your machine's available RAM. The upgrade is free (you have the license already) and takes under 10 minutes.
To switch to 64-bit Excel:
- Open Control Panel → Programs → Uninstall a program
- Uninstall the existing 32-bit Office installation
- Re-download from office.com → choose 64-bit installer
- Your activation transfers automatically — no license cost
Important: If any add-ins require 32-bit Excel specifically (rare, but exists in some enterprise environments), confirm compatibility before upgrading. Most modern add-ins support 64-bit.
After this fix: The ~2GB process ceiling is replaced by your machine's available RAM. On a 16GB machine, the effective Excel memory ceiling increases roughly 8×. Most persistent memory errors on 32-bit Excel do not recur after upgrading.
Fix 2: Pivot Table Memory Crash
Root cause: Creating a pivot table loads the entire source range into a pivot cache in memory simultaneously. For a 500K-row file with 20 columns, this cache can consume 2–4GB depending on data density.
Fix sequence:
- Pre-filter the data to only the rows and columns needed for the analysis before creating the pivot
- Create the pivot from a named table or defined range rather than a full-column range (e.g.,
A1:T500000rather thanA:T) - Disable pivot cache sharing if multiple pivots point to the same data
- After creating the pivot, delete the pivot cache: right-click pivot → PivotTable Options → Data → "Number of items to retain per field: None"
❌ INEFFICIENT (loads entire sheet into pivot cache):
Source range: A:T (all columns, all rows, including empties)
Memory consumed: ~3.8GB on test file
FIXED (loads only actual data range):
Source range: A1:T500001 (header + 500,000 data rows)
Memory consumed: ~1.2GB — same result, 68% less memory
For pivots on files larger than 500K rows, processing outside Excel's grid is the most reliable path.
After this fix: Pivot cache drops from 2–4GB to under 1.5GB in typical cases. Operations that previously crashed complete successfully. Pivot refresh time also typically drops 40–60% as a side effect of the reduced cache size.
Fix 3: Formula Recalculation Crash
Root cause: Volatile formulas — NOW(), TODAY(), RAND(), INDIRECT(), OFFSET() — recalculate every time any cell in the workbook changes. On large datasets, a single keystroke can trigger recalculation of thousands of cells simultaneously.
Fix sequence:
- Set calculation to Manual: Formulas → Calculation Options → Manual. Press F9 to recalculate when needed.
- Replace volatile formulas with non-volatile equivalents where possible: INDIRECT can often be replaced with direct references; OFFSET can often be replaced with INDEX
- Restrict SUMPRODUCT and array formula ranges to the actual data range:
=SUMPRODUCT(A2:A500001 * B2:B500001)not=SUMPRODUCT(A:A * B:B) - If using iterative calculation, verify the iteration limit is not creating runaway computation: File → Options → Formulas → Maximum Iterations (default 100)
After this fix: Recalculation no longer fires on every keystroke. For workbooks with heavy volatile formula use, switching to manual calculation typically reduces perceived lag from seconds to near-instant on the same file.
Fix 4: Sort or Filter Crash
Root cause: Sort loads the full sorted range into memory to rearrange it. On a 1M-row dataset with 20 columns, this temporarily requires two full copies of the dataset in memory — the original and the sorted output.
Fix sequence:
- Filter the data to the relevant rows before sorting — sort only what you need
- If sorting on a single column for ranking, add a helper column with RANK() instead of physically sorting the data
- For files over 500K rows, split the file first and sort each chunk
Fix 5: Save Failure
Root cause: The save operation must serialize the entire workbook — including undo history — into memory before writing to disk. If the workbook is near the memory ceiling, the save operation itself pushes it over.
Fix sequence:
- Clear undo history: save a copy of the file, close and reopen it — the undo stack is cleared on close
- Remove excess pivot caches: right-click each pivot → PivotTable Options → Data → "Number of items to retain: None", then save
- Strip embedded objects: images, charts, and embedded OLE objects inflate file size and memory footprint significantly
- Save as
.xlsxrather than.xlsor.xlsm— the XML-based format is more memory-efficient during save than legacy formats - If all else fails, split the workbook: separate sheets or data ranges into smaller files
Fix 6: Open Failure Before Excel Loads
Root cause: This variant ("There is not enough memory or disk space to run Microsoft Excel") appears before any workbook opens. It indicates a problem with Excel's launch environment — corrupted temp files, conflicting add-ins, or insufficient disk space for temp file creation.
Fix sequence:
- Check disk space: Excel requires free disk space to create temp files during launch — at minimum several hundred MB
- Clear Excel temp files: delete contents of
%temp%(type into Windows Run dialog) - Disable all add-ins: File → Options → Add-ins → Manage COM Add-ins → uncheck all, restart Excel
- Repair the Office installation: Control Panel → Programs → Microsoft 365 → Change → Quick Repair
When the File Is Simply Too Large for Excel
At this point, you are no longer dealing with a configuration problem. You have hit a hard architectural ceiling. Excel's processing model — single-threaded, full-dataset-in-memory — is not the right tool for data at this scale. Continuing to fight Excel's constraints wastes time that the data cannot give back.
Most cloud-based CSV and Excel tools process these files by uploading them to a remote server. For files containing P&L data, customer records, employee information, or any personally identifiable data, that upload creates exposure. Under GDPR Article 5(1)(c)'s data minimization principle, uploading to validate, split, or convert a file introduces a processing step that may not be necessary.
SplitForge processes files in Web Worker threads running in your browser. For the file's raw contents, nothing is transmitted to any server — verifiable by opening Chrome DevTools → Network tab during processing and observing zero outbound requests for file data.
FIXED — same 247MB file, browser tool:
Processing time: 38 seconds (in our testing, March 2026)
Memory usage: 2.1GB browser tab peak
Rows processed: 800,000 / 800,000
Data lost: 0
Test environment: Intel i7-12700, 32GB RAM, Chrome 122, Windows 11
Results vary by hardware, file complexity, and browser version.
Additional Resources
Official Documentation:
- Microsoft Excel specifications and limits — Memory and file size constraints by Excel version
- Excel 64-bit vs 32-bit information — Microsoft's guidance on upgrading from 32-bit
- MDN Web Workers API — Browser threading model for client-side file processing
Related SplitForge Guides:
- Excel Limits Complete Reference — All Excel memory and size constraints in one place
- Excel Slow on Large Files — When Excel doesn't crash but becomes unusably slow
- Reduce Excel File Size — Shrinking bloated workbooks before the memory error hits