Chrome Shortcuts (omnibox) forensics

History tells you where the user went. The Shortcuts database tells you what they typed to get there — including partial queries that never resolved to a full visit. It is one of the most direct intent artifacts Chromium leaves behind, and most triage workflows walk right past it.

Where it lives

A SQLite file named Shortcuts in the profile directory:

…\User Data\<profile>\Shortcuts

Edge is identical (…\Edge\User Data\<profile>\Shortcuts). It is small, sits beside History and Cookies, and is trivial to overlook because it has no extension and an unhelpful name.

What omni_box_shortcuts records

The single table that matters is omni_box_shortcuts. Each row is a learned address-bar completion the user accepted at least once:

The pairing of text and fill_into_edit is the prize: it shows the user's raw keystrokes next to the suggestion they accepted.

Why it beats History for intent

History only records completed navigations. Shortcuts captures the input — and that input is frequently a partial query. A user who typed bitc and accepted a completion to a specific exchange leaves a row even if you can't reconstruct the same intent from a URL visit alone.

• Partial typed text survives here when the full term appears nowhere in urls or keyword_search_terms.
• The chosen completion distinguishes intent from autocomplete noise: text is what they meant to type, url is where they went.
• number_of_hits is a habit signal. A high hit count means the user reaches this destination by muscle memory — a routine, not a one-off.

Timestamps

last_access_time is the Chrome/WebKit epoch: microseconds since 1601-01-01 UTC. Do not parse it as Unix time. Convert with the same routine you use for History.visits.visit_time, then correlate the shortcut's last use against the visit timeline and download rows.

Note the schema only stores last_access_time — there is no per-hit history, so number_of_hits is a running counter rather than a list of dated events. Treat it as frequency, not as a timeline.

How the tool parses it

BrowserForensics reads omni_box_shortcuts directly and surfaces, per row, the typed text, the completion (fill_into_edit), the destination url, the hit count, and the decoded last-used time. That is enough to answer the two questions that matter in triage: what did they type, and how often did they go there.

Pitfalls

• The file has no extension. Acquisition scripts that filter by *.sqlite or *.db will miss it. Collect by exact name.
• Shortcuts is a learned cache, not an exhaustive log. Absence of a row is not evidence the user never typed something — entries are pruned and only accepted completions are stored.
• It can carry a WAL (Shortcuts-wal). Copy the sidecar files and let the WAL be checkpointed, or recent rows may be missing.
• text is normalised (lower-cased, trimmed). Read it as intent, not as a verbatim keystroke transcript.

Further reading

• Chrome history database forensics
• Chrome history file locations
• Browser timestamp formats
• Where browsers store their artifacts