How to Restore Tabs After a Browser Crash (Every Browser, 2026)

By Kshetez Vinayak, founder of SupaSidebar. Last updated May 21, 2026.

When a browser crashes on Mac, the tabs are almost never actually gone. Every modern browser writes session state to disk continuously, not just on clean shutdown, which means the recovery file usually exists somewhere on the Mac even when the browser refuses to load it. Chrome, Edge, and Brave show a "Restore" dialog on the next launch. Firefox restores automatically from a recovery.jsonlz4 file that gets updated roughly every 15 seconds. Safari leans on macOS Resume. Arc attempts a silent automatic restore. The catch is the edge cases: force-quit during a system freeze, kernel panic mid-save, an iCloud-synced profile that gets restored on the wrong device, an Incognito window that intentionally leaves no trace. This guide covers the automatic crash recovery in every Mac browser, the manual session-file recovery when the automatic path fails, and the proactive setup that prevents tab loss from being a browser-crash problem at all.

TL;DR:

Relaunch the crashed browser and accept its automatic restore - Chrome/Edge/Brave show a Restore bar, Firefox shows "Restore Previous Session," Safari reopens silently via macOS Resume, Arc restores automatically. If the auto-restore fails: in Chromium browsers run open -a "Google Chrome" --args --restore-last-session from Terminal; in Firefox copy previous.jsonlz4 over recovery.jsonlz4 in the profile's sessionstore-backups/ folder. Incognito/Private tabs are never recoverable. Multi-browser users need a tab-storage layer outside any single browser - that's what SupaSidebar adds across 25+ Mac browsers.

Looking for something specific?

• Want to know what every browser saves and where? → Keep reading.
• Closed a tab manually, not a crash? → How to restore closed tabs in every browser
• Looking for an automatic session backup tool? → Tab Session Manager guide for Chrome and Firefox
• Want a Session Buddy alternative? → Session Buddy alternatives in 2026

---

What a browser actually saves during normal operation

Crash recovery only works because every major browser writes session data continuously. Understanding what each one writes, where it writes it, and how often is the difference between recovering tabs and giving up on them.

The Chromium-based browsers (Chrome, Edge, Brave, Arc) all use the same Current Session / Current Tabs files for the active session, then rotate them to Last Session / Last Tabs on the next launch. If a Chrome crash happens at 3:14 PM, the Current Session file from 3:14 PM is what becomes Last Session when Chrome relaunches, and the restore dialog reads from that file. Firefox's recovery.jsonlz4 is the live working file; previous.jsonlz4 is the rotated copy from the prior session.

Safari's behavior is different because the session state is partially in the browser and partially in macOS. The window-level state lives in ~/Library/Saved Application State/com.apple.Safari.savedState/. Tab content URLs are stored in Safari's own preferences. macOS Resume coordinates the restoration when Safari relaunches after a crash, which is why Safari almost always restores its previous state on Mac without any manual setting.

---

Restore tabs after a Chrome crash

Chrome's crash recovery is the most predictable of any browser because Chromium has been refining it for over a decade.

The automatic path

When Chrome detects an abnormal shutdown (process killed, app crashed, system rebooted without a clean Chrome exit), the next launch shows a small bar at the top of the new window asking to "Restore" the previous session. Clicking Restore opens every tab that was open at the time of the crash, in the same windows and the same order.

If the crash dialog does not appear automatically, two settings change the behavior:

1. Go to chrome://settings/onStartup
2. Select Continue where you left off

With this setting on, Chrome reopens the previous session on every launch, not only after a crash. The dialog disappears because the restore becomes the default.

What Chrome writes to disk during the crash window

Chrome maintains four files in the profile folder:

• Current Session - the active session state
• Current Tabs - the tab list for the active session
• Last Session - the previous session (becomes the source for restore)
• Last Tabs - the tab list for the previous session

Profile folder location on Mac:

~/Library/Application Support/Google/Chrome/Default/

(Replace Default with the profile folder name if using Chrome profiles. The folder lists them as Profile 1, Profile 2, etc.)

If Chrome's restore dialog fails (the most common cause: the session file was corrupted mid-write during a kernel panic), the previous session file may still be readable. Quit Chrome completely, copy Last Session and Last Tabs somewhere safe as a backup, then try relaunching Chrome with the --restore-last-session flag from Terminal:

open -a "Google Chrome" --args --restore-last-session

This forces Chrome to read the session file even if the auto-detect logic failed.

What Chrome cannot recover after a crash

Tabs opened in Incognito mode are gone. Chrome's Incognito explicitly does not write session state to disk - that's the entire point of the mode. A crashed Incognito window cannot be restored by any built-in method. The narrow exception: if the entire Chrome process crashed while Incognito tabs were open, Chrome will not offer to restore them. Bookmark the URL before closing private windows that contain anything worth keeping.

---

Restore tabs after a Safari crash

Safari's crash recovery is the most "just works" of any Mac browser because macOS handles half of it.

The automatic path

When Safari crashes or the Mac restarts unexpectedly, Safari will reopen its previous windows and tabs on the next launch. No dialog, no prompt - it just happens. This is macOS Resume doing the work, not Safari's own session manager.

For more control, change Safari's startup behavior:

1. Open Safari
2. Safari > Settings > General
3. Set Safari opens with to All windows from last session

This ensures Safari reopens every window on every launch, including after a crash or restart.

Where Safari stores session state

Safari's window and tab state lives in two places on Mac:

• ~/Library/Saved Application State/com.apple.Safari.savedState/ - window positions, tab arrangements, scroll positions
• ~/Library/Safari/LastSession.plist - the URLs of tabs in the previous session (older Safari versions) or per-window plist files in newer Safari builds

The Saved Application State folder is what macOS Resume reads when relaunching Safari. If this folder is deleted or corrupted, Safari forgets which windows and tabs were open. macOS rebuilds it on the next normal Safari quit.

Force-quit edge cases

If Safari was force-quit (Cmd+Option+Esc, then Force Quit), macOS still writes the saved-state files - the force-quit goes through macOS's app-termination flow, which gives Safari a final chance to flush state. The "Reopen all windows from last session" works after force-quit.

The case where Safari does not restore: holding the Shift key while Safari relaunches. This intentionally suppresses session restore, used when a corrupted page is crashing Safari on every launch. After the next clean quit, restore behavior returns.

What Safari cannot recover

Private Browsing windows do not persist after closure. Safari Private mode does not write session data, history, or cache to disk in a recoverable form. A crashed Private window's tabs are gone.

---

Restore tabs after a Firefox crash

Firefox has the most aggressive session-state persistence of any major browser, which makes it the most recoverable after crashes.

The automatic path

Firefox detects abnormal shutdown on launch and either restores the session automatically or shows a "Restore Previous Session" button on the new tab page. To make this the default on every launch:

1. Go to about:preferences#general
2. Under Startup, check Open previous windows and tabs

Firefox saves session state every 15 seconds by default (configurable via browser.sessionstore.interval in about:config), which means the most that gets lost in a crash is the last 15 seconds of tab activity.

Where Firefox stores session state

Firefox's profile folder on Mac:

~/Library/Application Support/Firefox/Profiles/{random-string}.default-release/

Inside sessionstore-backups/:

• recovery.jsonlz4 - the live recovery file, written every 15 seconds
• recovery.baklz4 - a backup of the previous recovery file
• previous.jsonlz4 - the session from the prior Firefox launch
• upgrade.jsonlz4-{version} - the session saved before a Firefox upgrade

These files are LZ4-compressed JSON. Firefox documents this format in the Session Restore knowledge base. Decompressing them requires lz4json or the Python lz4 library - the standard lz4 command-line tool will not decode them because Mozilla prepends a small custom header.

Manual recovery from session files

If Firefox's automatic restore fails (the recovery file got corrupted, or "Restore Previous Session" is greyed out), the previous session is often still recoverable from previous.jsonlz4:

1. Quit Firefox completely
2. Open the profile's sessionstore-backups/ folder
3. Rename recovery.jsonlz4 to something else as a backup
4. Copy previous.jsonlz4 to recovery.jsonlz4
5. Relaunch Firefox - it will attempt to restore from the renamed file

This works because Firefox treats recovery.jsonlz4 as the primary source of session state on launch. Swapping in the previous session's file fools Firefox into restoring the older session.

What Firefox cannot recover

Private Browsing windows are designed to leave no on-disk session record. There is one documented edge case: if Firefox itself crashes (not just the Private window being closed normally), Firefox may attempt to restore the Private window as part of crash recovery. This behavior is not guaranteed and is not configurable.

---

Restore tabs after an Edge crash

Microsoft Edge is Chromium-based, so its crash recovery is functionally identical to Chrome's with a few naming differences.

The automatic path

Edge shows a restore prompt after a detected crash. To enable session restore on every launch:

1. Go to edge://settings/onStartup
2. Select Open tabs from the previous session

Where Edge stores session state

Profile folder on Mac:

~/Library/Application Support/Microsoft Edge/Default/

The session files (Current Session, Current Tabs, Last Session, Last Tabs) follow the same Chromium pattern as Chrome. Recovery commands also work the same way:

open -a "Microsoft Edge" --args --restore-last-session

What Edge cannot recover

InPrivate tabs are not recoverable after a crash. Edge's InPrivate mode follows the same no-disk-trace rule as Chrome Incognito.

---

Restore tabs after a Brave crash

Brave's Chromium foundation means its crash recovery mirrors Chrome and Edge.

The automatic path

Brave shows a restore dialog after a detected crash. To make session restore the default:

1. Go to brave://settings/getStarted
2. Under "On startup," select Continue where you left off

Where Brave stores session state

Profile folder on Mac:

~/Library/Application Support/BraveSoftware/Brave-Browser/Default/

Same file structure as Chrome (Current Session, Last Session, etc.). Same Terminal command:

open -a "Brave Browser" --args --restore-last-session

What Brave cannot recover

Brave's Private and Private with Tor windows do not retain session state on disk. Tor windows additionally route traffic through the Tor network, but both variants discard tab data on close.

---

Restore tabs after an Arc crash

Arc handles tabs differently from traditional browsers because of its auto-archive and sidebar model, which actually makes crash recovery easier in most cases.

The automatic path

When Arc crashes, it attempts to restore the previous session on the next launch. There is no explicit "Continue where you left off" setting - the behavior is automatic.

Arc's auto-archive system also reduces the impact of tab loss. Tabs in the sidebar are moved to the Archive after a configurable period (12 hours by default). Even if the crash recovery fails to restore active tabs, archived tabs are not lost - they remain in the Archive accessible from the sidebar or via Cmd+T search.

What Arc cannot recover

Arc is in maintenance mode following The Browser Company's October 2024 announcement - see our Arc browser status tracker and is Arc dead? for the long-term outlook. The session restore behavior is not expected to change, but any crash recovery improvements that Chromium ships upstream may not be backported to Arc. Arc's Incognito-style "Little Arc" windows are also not recoverable after a crash.

---

The hard cases: when automatic recovery fails

Most crash recoveries succeed silently. When they fail, one of these scenarios is usually the cause.

Force-quit during a system freeze

If macOS itself froze (rainbow wheel, no input response) and the Mac was hard-rebooted with the power button, the session file may have been mid-write when the power cut. The file gets truncated, the next browser launch reads a partial session, and the restore either fails entirely or restores an outdated session.

What to do:

1. Do not launch the browser yet. Each launch consumes the rotation slot.
2. Open the profile folder in Finder (paths above)
3. Make a copy of every session-related file before doing anything else
4. Try the browser's automatic restore once
5. If it fails, use the manual recovery steps above (Firefox: swap previous.jsonlz4 into recovery.jsonlz4; Chromium: use the --restore-last-session flag)

Kernel panic mid-save

Kernel panics interrupt every running process, including the browser writing session state. If the panic happened during a session-file write, the file is partially written. Chromium browsers handle this reasonably well because they keep the previous version. Firefox's 15-second backup interval almost always saves something usable. Safari is the most resilient because macOS coordinates the saved-state writes through a separate process that is less likely to be in the middle of a write.

Sync conflicts after restoring on a different device

iCloud-synced Safari profiles, Chrome Sync, Firefox Sync, and Edge Sync all coordinate session state across devices. If a Mac crashed mid-sync, the cloud copy and the local copy may disagree on which tabs were open. The local recovery file usually wins on the next launch - Chrome and Firefox both prioritize local session state over synced state during restore.

The case that breaks this: if a user opens the browser on a second device (iPad, second Mac, or Windows machine) before restoring on the crashed device, the cloud session gets updated to reflect the second device's tabs. Restoring on the original Mac may then pull the second device's session instead of the local crashed session. Avoid opening synced browsers on other devices until the crashed Mac's restore is complete.

Profile corruption

If the entire browser profile is corrupted (not just the session file), automatic restore will fail and manual recovery will fail too. Browser profiles can be recovered from Time Machine if the Mac is backed up. Safari's profile is partially backed up via iCloud if iCloud Safari sync is enabled. Chrome, Firefox, Brave, and Edge profiles are local-only and depend on Time Machine for backup.

This is the worst case in the entire crash-recovery flow because both the live session file and its backups can be unreadable. A 2025 r/firefox thread titled "Firefox crashed, deleted all my bookmarks when restarted, and won't let me restore backups" captures the failure mode: a crash that corrupted the profile, an automatic restore that ran but produced a stripped state, and backup files Firefox would not load. The 84-upvote post is a useful signal that this scenario does happen to real users and is not just a theoretical edge case. Time Machine, if enabled, is usually the only path back when this happens.

---

Setting up automatic crash protection

The automatic restore in every browser is good but reactive - it only triggers after a crash and only works within that one browser. For a more proactive setup, three additions help.

Session manager extensions

Tab Session Manager (Chrome, Firefox, Edge) is the most-used option. It automatically saves a snapshot of every window's tabs at a configurable interval (default 15 minutes), keeps a history of named sessions, and lets users restore any past session. The advantage over native session restore: the snapshots are saved as named, dated entries, so a session from yesterday afternoon is recoverable even if a clean shutdown happened since then. The Tab Session Manager guide covers setup and workflow.

Session Buddy is another Chrome extension in the same category. Its development pace has slowed, so Session Buddy alternatives in 2026 covers options that are actively maintained.

The hard part of extension-based session managers: they only work in the one browser they are installed in. A multi-browser workflow needs the extension in each browser, and the saved sessions don't talk to each other.

A separate warning that applies to any browser-extension setup: do not install The Great Suspender. Google delisted it from the Chrome Web Store in February 2021 after the original developer sold the extension and the new owner shipped malware. The Marvellous Suspender (an open-source fork) and Auto Tab Discard are the safe replacements.

Browser sync as a backup layer

Chrome Sync, Firefox Sync, Edge Sync, and Safari iCloud sync all push tab data to the cloud. This is not session-restore in the strict sense (a closed tab is not the same as an "open tab on another device"), but it is a useful backup layer when local recovery files are corrupted. The synced "Open tabs on other devices" list can recover URLs even when the local crash-recovery file is unreadable.

Limitations: sync is per-browser. Firefox Sync does not see Chrome tabs. Chrome Sync does not see Safari tabs. The "Open tabs" list is also read-only on most browsers - it shows URLs but does not actually reopen them in their original context.

Tab storage outside the browser

The crash-recovery problem is structurally a problem about where tabs live. As long as tabs live only inside the browser's session file, a crash that corrupts that file means manual recovery. As long as tabs live only inside one browser, a sync conflict means tabs are missing on the device that needs them.

SupaSidebar takes a different approach: tabs that matter live in a sidebar outside the browser. SupaSidebar is a macOS app that brings Arc's sidebar to every browser - one sidebar for tabs, bookmarks, files, and apps across 25+ browsers including Safari, Chrome, Firefox, Arc, Zen, Vivaldi, Brave, Helium, and Dia. Smart Save (⌘⌃S) captures any open browser page to the sidebar in one shortcut. Once a tab is in the sidebar, a Chrome crash does not affect it. A Firefox profile corruption does not affect it. A force-quit of any single browser does not affect it.

This is not a replacement for browser session restore - the sidebar does not capture every open tab automatically (that would be a privacy and storage problem). It captures the tabs explicitly saved with Smart Save, which is the workflow for tabs worth keeping. The browser's own session restore handles the long tail of casually-open tabs after a crash. The sidebar handles the tabs that would actually hurt to lose.

The other piece is Live Tabs. SupaSidebar's sidebar shows tabs from every running browser in real time, so a user who works across Chrome, Safari, and Firefox sees one unified inventory instead of three browser windows each with their own tab pile. After a crash, the Live Tabs view shows which browser's tabs were affected (the Live Tabs from a crashed browser go away when that browser exits), which makes triage faster than alt-tabbing through every browser window to find a tab.

iCloud sync handles cross-device persistence. Tabs saved on the Mac that crashed are still in the sidebar on a different Mac, because the sidebar's storage syncs through iCloud independently of any browser's sync system. A Mac that crashes hard during a session does not lose the saved sidebar content - it lives on iCloud and resyncs when the Mac comes back online.

---

Quick reference: crash recovery by browser

---

Conclusion: What to do after a browser crash

For the immediate aftermath of any browser crash, the answer is the same: relaunch the browser and accept its automatic restore. Chrome, Edge, and Brave will show a Restore bar. Firefox will show a Restore Previous Session button. Safari will quietly reopen everything via macOS Resume. Arc will silently restore. The automatic path handles >90% of crash scenarios on Mac.

Single-browser users on Chrome, Edge, or Brave should enable "Continue where you left off" in startup settings (how to save tabs in Chrome covers the full workflow), which makes the restore behavior the default and eliminates the prompt. Firefox users should leave session-restore enabled and rely on the 15-second recovery.jsonlz4 write interval - it is the most aggressive on-disk persistence of any major browser (how to save tabs in Firefox walks through the related export workflow). Safari users should set "Safari opens with: All windows from last session" and let macOS Resume coordinate the rest. Arc users get crash recovery automatically.

Multi-browser users on Mac face a different problem: every browser's crash recovery only sees its own tabs, and the workflow that spans Chrome plus Safari plus Firefox cannot be restored from any single browser's session file. One Reddit user captured the typical pattern: "I used to Arc, but it kept crashing on me. So I switched to Safari. I really miss the sidebar (from Arc) and I want to change my browser to either Edge, Chrome or Brave" (anonymous r/macapps comment). The browser switch happened because of crash frustration; the sidebar gap is what carried over. The proactive approach is to capture the tabs that matter into a tab storage layer outside any one browser - a session manager extension per browser, or a Mac sidebar app that holds tabs across all of them. For power users running 3+ browsers, that second option is usually the only way to keep crash recovery from becoming a triage exercise across multiple session files.

Try SupaSidebar (free tier)

---

Why we recommend SupaSidebar

SupaSidebar is a macOS app that brings Arc's sidebar to every browser - one sidebar for tabs, bookmarks, files, and apps across 25+ browsers including Safari, Chrome, Firefox, Arc, Zen, Vivaldi, Brave, Helium, and Dia. Instead of relying on each browser's own session-restore file to recover from a crash, SupaSidebar's Smart Save (⌘⌃S) captures any browser page into a sidebar that lives outside the browser entirely. A crashed Chrome, a corrupted Firefox profile, or a force-quit Safari does not touch the sidebar's storage. The saved content syncs across Mac devices via iCloud, so a hard crash on one Mac does not lose the saved sidebar on another. Live Tabs shows every running browser's tabs in one panel for fast triage after a crash. For multi-browser Mac workflows, the sidebar is the crash-proof layer the browsers themselves cannot be.

---

FAQ

---

By Kshetez Vinayak, founder of SupaSidebar.