browserforensics
← Back to all articles

Chrome session restore (SNSS) forensics

2026-06-21 · 4 min

Chrome remembers what you had open. The Sessions files let it restore your windows and tabs after a crash or a restart, and they let you reopen recently-closed tabs from the menu. For an examiner that means a snapshot of the tabs that were live at the last run — including pages a user may have visited in a private-feeling way but never expected to leave a second copy behind. The data is corroborating gold when History is missing or wiped.

Where the files live

Inside the Chromium profile (Default, Profile 1, …):

  • Sessions\Session_<timestamp> — window and tab state for the current run.
  • Sessions\Tabs_<timestamp> — recently-closed tabs and tab groups.
  • Legacy builds wrote Current Session and Current Tabs at the profile root, plus Last Session / Last Tabs (the previous run, kept for "restore"). You will still meet these on older images.

The <timestamp> in the filename is a Chrome-epoch value (microseconds since 1601-01-01 UTC), so the newest file is the live session. Chrome keeps a small number of the most recent files and prunes the rest.

The SNSS format

SNSS stands for Simple Native Serialized Sessions. The layout is small:

  • A 4-byte magic, SNSS.
  • An int32 version (1 or 3 in the wild).
  • A stream of length-prefixed command records. Each record is an int16 length, then a 1-byte command id, then the payload.

Each command id encodes one mutation of session state. Replaying the stream from start to end rebuilds the windows and tabs as Chrome would on restore. The commands you care about:

  • Window and tab creation — establishes the IDs everything else references.
  • Navigation entries — a tab's SetTabNavigation records carry the URL, the page title, the navigation index, and the serialized PageState (form data, scroll position, POST blobs).
  • Selected tab index and selected window — what was focused.
  • Tab and window close commands — so a naive "last URL per tab" read can be wrong if you ignore closes.

Because it is a replay log, the same tab id can appear many times. Read it as a stream of edits, not a table. The current navigation index tells you which of a tab's many entries was on screen; the earlier entries are that tab's in-session back/forward history.

Forensic value

  • Reconstructs the set of tabs open at the last run, with titles and full URLs, even when History has been cleared — the two stores are independent.
  • Tabs_ / Current Tabs give you recently-closed tabs and groups, a short-window record of activity the user may have deliberately closed.
  • PageState can hold form input and POST data that exists nowhere else.
  • Pair every recovered URL with History (urls/visits) and the -wal sidecar for corroboration and visit timing. Sessions tell you what was open; History tells you when and how often it was visited. See build a browser activity timeline.

Tool support — be honest

This in-browser tool does not yet parse SNSS. Chrome Session_ / Tabs_ (and the legacy Current Session / Current Tabs) files are a manual / parser-needed artifact for now: treat them as something you carve or run through a dedicated SNSS parser, not something you can drop into this app and read.

What the tool does parse today is Firefox session restore (sessionstore.jsonlz4 / recovery.jsonlz4), which carries the equivalent open- and closed-tab data in Mozilla LZ4-wrapped JSON — see Firefox session restore. If your case is Chromium, plan to handle Sessions out of band until SNSS support lands.

A few practical notes for the manual route:

  • Collect the whole Sessions\ directory, not just the newest file — Last Session and pruned-but-not-yet-deleted files can survive.
  • Files are append-mostly; deleted or overwritten commands may linger as carve-able fragments in slack.
  • The format is undocumented by Google and has shifted across versions, so validate any parser against the magic and version bytes before you trust its output.

Further reading