Your search history: the unintentional self

Posts are performances. Stories are performances. Even likes are half-performances —
tiny public-ish signals you chose to leave behind. The search bar is the one place
in the whole platform where you typed something before you knew whether you'd
follow through: a name you looked up at 1am, a symptom, an ex, a job title, a city
you were considering moving to. Nothing was published. Nobody was watching. And
then it landed in your export anyway — as a plain row with a term and a time.

This post is about that list: where it physically lives in the archive (it is less
"one file" than you'd think — five sources, four kinds), what each kind actually
records, how this product surfaces it without editorialising, the sample limit
that decides how much of it exists, and why a list of unperformed thoughts is the
closest thing an export has to a longitudinal portrait of a mind at work.

1. 2minthe five source files and what each of the four kinds records.
2. 4minthe emotional read: why unposted thoughts age differently than posts.
3. 5minwhere to see it in the app, and the limits that bound the list.

Where the list physically lives

Under logged_information/recent_searches/ the export hands you up to four JSON
files, plus a legacy file at the activity root and an HTML equivalent in older
archives:⁵

Three record shapes hide behind those filenames — label-value rows
(Search query / Update time), string-map rows (Search + a time key), and
plain string lists — and the parser reads all three into the same four fields:⁶

• value — the term, the username, the hashtag. The thing you typed.
• href — a profile link when the record carries one (profile searches

  usually do).

• timestamp — when the platform says you searched, when it says anything.
• title — the raw label as written; sometimes the only place the term

  exists (modern profile exports are title-only, and the parser knows to read it
  there).

For JSON exports the four kinds stay separated end to end — parser, Insights,
heatmap modes, the works. For HTML exports, the three typed buckets come back
empty and everything is one merged list: a format limitation, not a data
difference.⁴ The activity post documented the merge rule from the other
side; here the point is what the split means.

What each kind records — and why the difference matters

Profile searches are the people list: every account you typed into the search
bar. This is the kind that reads like a diary entry you never meant to write,
because looking someone up is a complete action with no public residue — you
can check on someone a hundred times and they will never know once. The app knows
this is the emotionally loaded one: the per-account page has a "Times you
searched for them" chart, and the accounts directory can filter and sort by
"Has searches" / "most searches".⁷

Tag searches are your curiosity by topic — the hashtags you opened to see what
was inside them. Moods, fandoms, causes, events. A tag search is a step past
interest: you didn't just hear the word, you went to look at its river.

Keyword searches are the free-typed queries: half-thoughts, questions,
symptoms, songs, "how to know if…". The rawest of the three, because a typed
phrase is closer to speech than to navigation.

Recent and legacy lists fill in the rest — whatever the platform's generic
log captured. The parser merges them rather than inventing a fifth category the
product cannot name honestly.

The Insights page's caveat is worth repeating because it is the whole editorial
position: the four kinds are different actions, and any product that sums them
into one "searches" number has destroyed the only interesting property of the
data — which of these were you reaching for people, topics, or answers?²

Anatomy of a single row

Before the emotional read, one sober minute with the object itself, because
everything above is abstraction over four strings. A profile-search row in a
modern JSON export looks, stripped to its shape, like this:

{
  "title": "someone_from_years_ago",
  "href": "https://www.instagram.com/someone_from_years_ago/",
  "string_map_data": {
    "Update time": { "timestamp": 1712345678 }
  }
}

(Illustrative. Synthetic username — real handles never appear in this
repository's examples.) Three of the four record fields are visible:
title carries the term, href the destination when there is one, and the
timestamp under its raw Unix form. Older exports use a different wrapper —
a Search query label paired with an Update time value — and some files are
nothing but a bare list of strings with no time at all. The parser reads all
three shapes into the same ActivityRecord so the rest of the product never
has to care which era it is looking at.⁶

That uniformity is also why the honest limits are structural rather than
defensive: a row literally is four fields. When the product says a search
carries no outcome, that is not modesty — there is no fifth field to read.
When a heatmap cell is empty for an hour, either nothing was searched or the
row for that hour had no readable time; the record cannot distinguish those
two cases, so the views don't pretend it can.

Checking any of this against your own file

The claims in this post are filesystem claims, and they are cheaply verifiable
on your own machine:

1. Unzip your export and find logged_information/recent_searches/ — count

   the JSON files present. Four in a current JSON export; fewer if you chose a
   narrower download, none if the category was excluded.

2. Open one and read the wrappers. If every row has a string_map_data block

   with a timestamp, your rows are dated; if the file is a bare string list,
   yours are undated — which is why totals and heatmap cells can disagree.

3. If you requested the HTML format instead, look for search_history.html

   and note the absence of any profile_searches sibling: the split is gone at
   the source, not hidden by any viewer.

4. Compare your file's row count against the sample cap: if you see a number

   in the low hundreds on an account you have used for a decade, you are
   looking at the platform's 100–500 window, not your life.

A tool that cannot survive that four-step check is not worth trusting with the
list, and this one is built to. Every number on the views above can be traced
back to a row you can open in a text editor — that is the whole contract of a
local-first reader: the file stays yours, the derivation stays visible, and if
the two ever disagree, the file wins.

The unintentional self

Here is the property that makes this list unlike anything else in the archive: a
search is recorded before you knew how you felt about the result. You hadn't
decided yet. There was no audience, no curation, no even-self-consciousness — the
term you typed was the unedited version. Psychologists studying "self-regulation"
would call some of these goal-related search; a reader of their own list usually
just calls it embarrassing, then accurate.

Three properties make it longitudinal in a way posts are not:

1. Repetition without performance. Searching the same name thirty times over

   four years would be bizarre to publish and is completely normal to do. The
   list therefore tracks attention — the thing people actually want from a
   journal — without the distortion of an audience watching the tracker.

2. Pre-decision moments. A search usually sits before the action: looking up

   a person before a message, a hashtag before a follow, a symptom before a
   doctor, a city before a trip. It is the archive's only "thinking" layer —
   everything else records what happened, this records what you were considering.

3. Nothing to curate. Because searches were never visible, nobody prunes them

   for taste. The embarrassing and the profound get the same font size, which is
   exactly why the list feels more honest than your feed ever could.

The healthy way to read it is as weather, not as testimony: a record of what the
mind passed through, with all the context the file lacks (see the limits below).
The unhealthy way is to treat every row as a revealed preference carved in stone.
Both readings are available to you; only one of them is supported by the data —
and the app's job is to show the rows, not to pick one.

Where you can see it in the app

• The heatmap's four search modes — All Searches, People Searches, Tag

  Searches, Keyword Searches — each a day-hour grid of that kind only, with its
  own search box underneath ("Search people you looked up by username…", "Search
  hashtags you looked up…").⁹

• Insights' search section — "Searches you ran", "People you looked up", a

  section head that says the quiet part: "Instagram splits searches into four
  files — they are not the same thing."²

• Per-account pages — the "Times you searched for them" chart per person:

  distribution across time for one lookup relationship.⁷

• The accounts directory — filter to accounts you've searched, sort by

  search count.⁷

• Ask-anything — "what did I search for in 2023" runs as a retrieval query

  over the same records; the index covers searches alongside messages, captions,
  hashtags and links.¹⁰

• Compare — search totals and profile-search totals as side-by-side metrics

  between two exports, with the sample caveat attached to the number.³

Everything above is derived in the browser from the rows in your ZIP. Nothing is
uploaded, nothing is enriched, nothing is inferred.

The limits, in the order they bite

It is a sample — the platform's own export cap. The comparison view's caveat
states it plainly: "Instagram only lets you export your most recent 100–500
searches, so treat this as a sample rather than a total."³ "Recent" does
the heavy lifting: your earliest searches — sometimes most of them — are simply
outside the window. Counts are therefore floors, never ceilings: "412 searches"
means at least 412, from a slice.

Four kinds only exist in JSON exports. If your archive came down as HTML, the
typed buckets are empty and the parser hands you one merged list — same rows,
lost categorisation.⁴ The product shows what the format supports rather
than guessing which file each row came from.

Timing needs a readable timestamp. Rows without a parseable time still count
in totals (the taxonomy deliberately never filters them) but never enter a heatmap
cell or a dated chart — so "searches by hour" is built from the dated subset, and
the two numbers can legitimately differ.¹¹

A search is a term, not an outcome. The record does not say what you found,
whether you clicked, whether you messaged the person, or whether you closed the
app afterwards. It also does not know why — the same string is a joke, a worry
and a homework assignment in three different rows. Any story the list seems to
tell is a story you supply from memory; the file's contribution is the when and
the how-often, delivered flatly.

No feelings, no blocks, no receipts — the standing rule. The product never
characterises a person's inner life from data, and searches are not an exception
because they feel more intimate.⁸ The intimacy changes how you should
read the list, not what the software is allowed to say about it.

Questions this comes up

The what's-in-the-export post for the folder this list came from and the
four-kinds inventory; the activity post for the parser's merge rule; the heatmap
post for how any timestamped record becomes a day-hour cell; the person-in-your-
archive post for the profile-lookup layer that profile searches feed.

¹: packages/shared/src/parsers/activity.ts — five sources collected and
concatenated into searches: profile/tag/word-phrase/recent path predicates plus
the legacy searches.json record reader; the typed buckets are kept as separate
arrays alongside the merge.
²: apps/web-next/src/views/Insights.tsx — section "What you searched for"
("Instagram splits searches into four files — they are not the same thing") and
its caveat: keyword, hashtag and profile searches "are different actions and are
counted separately. The old tab merged them into one meaningless number."
³: packages/shared/src/analytics/compare.ts — the in-product caveat:
"Instagram only lets you export your most recent 100–500 searches, so treat this
as a sample rather than a total."
⁴: parsers/activity.ts — HTML path collects search_history.html into the
merged list and returns empty profile/tag/keyword buckets by construction.
⁵: parsers/activity.ts — path predicates for
logged_information/recent_searches/{profile,tag,word_or_phrase,recent}_searches.json
and legacy searches.json; parsers/html-to-json.ts — the HTML→JSON bridge for
search_history.html.
⁶: types/activity.ts — ActivityRecord { value, href, timestamp, title };
parsers/activity.ts — three extractors (label-value, string-map, string-list)
and the title-only fallback for modern profile exports.
⁷: views/AccountProfile.tsx — "Times you searched for them" and the
per-account search chart; views/Accounts.tsx — "Has searches" filter, "most
searches" sort, "You searched" column.
⁹: components/ActivityHeatmap.tsx — the four search modes with labels and
tips; views/Activity.tsx — per-mode search-box placeholders.
¹⁰: packages/shared/src/ama/intents.ts — "Times you searched them" row;
views/Ama.tsx — the index covering searches alongside messages, captions,
hashtags and links.
¹¹: analytics/activity-taxonomy.ts — raw counts "never timestamp-filtered"
beside a separate dated count, which is why heatmap cells and record totals can
legitimately differ.
⁸: ama/tone.ts — the refusal contract for questions about inner life
("why did they stop texting me — the archetypal unanswerable question"); the
product's no-feelings-inference rule applies to query text exactly as it applies
to messages.