Safari 26 is misbehaving for some users. With only a handful of tabs open, Activity Monitor reports Safari using more than 200 GB of memory. Your Mac keeps running, but Safari turns sluggish, stops registering keystrokes, and then crashes. The numbers look comical as users told. The experience though, you wouldn’t want that happen to you.
The memory usage sneak peek
A captured Activity Monitor session tells a clear story. Safari’s “Memory” column balloons past 200 GB while the system’s overall pressure stays low and swap remains at zero. That mismatch points to runaway allocations that the OS immediately compresses. Safari struggles anyway because its own event loop is starved.
| Metric (from screenshot) | Value |
|---|---|
| Safari Memory (column) | 231.79 GB |
| Safari Real Mem | 18.84 GB |
| Physical Memory | 48.00 GB |
| Memory Used | 34.54 GB |
| App Memory | 29.13 GB |
| Compressed | 1.83 GB |
| Swap Used | 0 bytes |
The discrepancy between “Memory” and “Real Mem” suggests a torrent of allocations that compress well, which explains low pressure and no swap. It does not save Safari from stuttering.
A thread on r/MacOS surfaces multiple reports matching this pattern. Users describe four to six tabs pushing Safari’s reported memory into triple digits, followed by input lag, tab sluggishness, and eventual crashes. Several comments note that memory compresses to near nothing while Safari remains unresponsive, which is consistent with a tight allocation loop inside WebKit or a related component.
It’s not the first time we have seen memory leak bugs in macOS Tahoe. Early adopters reported similar issues in system apps. The Calculator bug is just the latest example of a deeper memory management problem Apple hasn’t fully addressed.
Why this looks like a real leak, not just a UI glitch
Activity Monitor can mislead if you fixate on a single figure, but the behavior here lines up with a classic leak.
- The “Memory” column explodes while “Real Mem” rises more slowly. That hints at allocations that never free and compress into tiny blocks.
- Safari becomes unresponsive. Input lag means the main thread or event loop is busy, likely starved by allocator churn or IPC overload.
- The app crashes shortly after. That fits a process hitting internal limits, not the system running out of RAM.
What you can do right now
You should treat this as a Safari 26 regression. Until Apple ships a fix, do the basics that contain memory leaks and isolate triggers.
- Quit and relaunch Safari when you notice input lag.
- Disable or remove extensions you do not need. Test in a fresh profile.
- Clear website data and cached files.
- Turn off experimental features you enabled in Develop settings.
- Avoid leaving long-running tabs with heavy scripts idle in the background.
- If the issue returns quickly, use another browser for the session.
If you want Apple to fix it fast, send evidence.
- In Activity Monitor, select Safari, click the gear icon, and choose Sample Process. Save the sample.
- Trigger a sysdiagnose with Shift + Control + Option + Command + Period, then file a report in Feedback Assistant with the sample and exact time of the spike.
- Include your Safari version, macOS build, active extensions, sites open when the spike started, and whether video or WebGL was running.
What Apple should fix
Two fronts matter. First, plug the leak. The pattern points to a WebKit component allocating aggressively, then relying on the kernel to compress blocks that never get released. That keeps the system alive but grinds Safari’s UI. Second, audit how Activity Monitor surfaces per-process “Memory” for multi-process apps. The “Memory” figure here clearly confuses users and obscures the timeline of failure.
You can keep working because macOS compresses memory well. Safari still fails because the browser drowns in its own allocations. Treat this as a real Safari 26 bug, not a cosmetic counter issue. Capture evidence, file it, and use a temporary workaround until an update lands.
