Eight things your Instagram export can never bring back

The searches that bring people to posts like this one have a very particular shape:
recover deleted DM instagram export. Can I get my old posts back from the ZIP. The
phrasing almost always assumes there is a folder nobody told you about, where the
removed things are kept, and a better request format would unlock it. There is no such
folder. This post is the honest inventory instead: eight things that no export — no
format, no re-request, no tool — brings back, why each one is absent, and what the
archive puts in its place.

It sits beside why your export is missing half your life, and the two are deliberately
different. That post explains structural absence: data that exists but has not
landed in your files yet — the recent window a new request would include, the folder
your format choice skipped. Re-downloading genuinely helps there. This post is about
the other category: things where a re-request changes nothing, because the thing was
either deleted before the snapshot was taken, never yours to begin with, or designed
to delete itself.

1. 2minthe table: eight items, why each is gone, what exists instead.
2. 6mineach item with its file-level evidence and its partial substitute.
3. ongoing — the re-download test: when re-requesting helps, and when it never can.

The three kinds of gone

Everything absent from an export falls into exactly three categories, and the
categories are worth internalising before the list, because they tell you what to do
about each:

1. Deleted before the snapshot. The export is a copy of what exists when the

   request runs. Anything removed beforehand is not "missing" — it was never in scope
   for the copy. Your deleted posts, your removed conversations, an expired story.

2. Never yours to begin with. Another account's record of their actions toward

   you — who blocked you, who viewed what — lives on their side of the platform, and
   an export of your account cannot reach it. This is a custody boundary, not a
   deletion.

3. Designed to disappear. Unsent messages and vanish-mode chats delete themselves

   on purpose. The design goal was that they leave; an export faithfully respecting
   that goal has nothing to copy.

The rest of this post walks the list in order, because each entry has one honest
substitute and one common false hope attached to it.

1. Posts you deleted

The subtle one. Your export does contain a recently_deleted_content/ area, and
this site's parser collects it as its own bucket: files matching
recently_deleted_content/*.json and recently_deleted_content.json are read
separately from live posts, stories and reels, so they never blend into your actual
feed.¹ That is the platform's own recently-deleted grace window showing up in
the archive — deletions recent enough to still be recoverable on the platform appear
here too.

The honest limit: the window is the platform's, not yours, and it is short. A post
deleted long before your request is not in recently_deleted_content because it is no
longer in the platform's recently-deleted state — it is gone from the account's
records that the export reads. So the answer to "can I get my deleted posts back from
the ZIP" splits cleanly: recently deleted, possibly a partial yes via that folder;
long deleted, a no that no format changes. And note what a deleted post takes with
it: its likes, its comments, and the replies under it. Those were recorded on the post
— deleted post, deleted engagement history — which is why item 8's totals have holes
in exactly the shape of your removals.

2. Conversations you deleted

When you delete a conversation from your inbox, the thread is gone from your account's
message records, and the export copies your account's message records. What this site's
own request guide says plainly: deleted and unsent messages are not in the export — a
deletion is the end of the record, not a stage of it.² The surviving threads stay
intact and complete; the removed one is not a partial file, not a redacted file, and
not a file at all.

The frequently hoped-for nuance — "the other person's copy must still exist" — is
true but useless to you: their thread lives in their account's records, and you cannot
request those. Your export is strictly yours. Two people in a conversation can hold
two different archives of it, and if you deleted yours, no request restores it.

3. The text of unsent messages

Unsent messages are the cruellest entry on this list because the export keeps evidence
them and not the words. When a message carries is_unsent, the parser maps its type to
unsent and the app renders it as the literal string "Message unsent" — the presence is
visible, the body is not reliably recoverable, and nothing invents it.³ The
messages post covers the field mechanics; what matters for this list is the
classification: unsent content is designed to disappear, and the marker is the
platform leaving a tombstone rather than a hole.

Reading a thread with "Message unsent" rows in it is therefore reading a record with
its own deletions acknowledged — which is more honest than silence, and considerably
less satisfying than recovery. The tombstone tells you that something was removed and
where in the conversation it sat. It never tells you what it said. Any tool, service
or person claiming to reconstruct unsent text from an export is working from something
other than your export.

4. Vanish-mode messages

Vanish mode exists so that a message removes itself once the conversation closes — the
platform's term for content that deletes itself on read-and-leave. A later export has
nothing to copy: by the time your request runs, the design has already done its
deleting. This is category three again, and it is the cleanest case for the principle
in this post: the absence is not an export defect; the export would be lying if it
showed the messages and vanish mode were working as promised.

What remains is everything around them. The thread keeps its other messages, its
reactions, its media. A conversation that used vanish mode for one stretch and normal
messages for the rest exports with a gap shaped exactly like that stretch — and the
gap is the feature having functioned.

5. Expired stories, and their viewer lists

Stories are the export's most common surprise-absence because the platform's own
retention rules decide what an archive can hold: an unarchived story expires roughly a
day after posting, and its viewer list does not survive even that — this site's FAQ
notes viewer lists persist around 48 hours on the platform side and are never archived
into your account's records at all. What lands in your export's stories/ area is
therefore whatever survived the platform's rules: stories you archived, stories you
highlighted, and story interactions (stories you viewed, likes you gave, sticker
answers) recorded separately under activity.⁴

So the taxonomy for a story is: expire unarchived → gone before the snapshot (category
one); archived or highlighted → present; viewer list → never yours (category two), for
every story, every time. "Who watched my story" is on the five-questions list for
exactly this reason — even a story you still hold never carried other people's viewing
records into your account.

6. Who blocked you

Category two's textbook case: a block is their account's record of their decision,
stored on their side, and your export can only request what belongs to you. The
five-questions post walks this one in depth; the short version for this list is that
no format, media type or re-request reaches into another account's relationship files,
and the platform's refusal to hand you that list is a custody boundary working as
designed rather than a gap in your file.

What your export does contain is the mirror image: blocked_profiles.json /
blocked_accounts.json under the followers-and-following material — accounts you
blocked, parsed as the blocked relationship list.⁵ Your boundaries are in
the archive; theirs are not, and were never going to be.

7. Who viewed your profile

Neither direction of this exists: the platform does not surface profile views to
account holders in an export, and there is no folder where someone else's visits to
your profile would live, because those visits were never recorded as your data.
Again the five-questions post owns the full reasoning; for this taxonomy the entry
matters because it is the single most requested impossible item — the search that
brings most people to this page — and its classification is a hybrid: the viewer's
action (category two, theirs) plus a metric nobody receives (a platform-side
aggregate). Both roads end at the same no.

8. Reach, impressions and engagement totals

Insights-style numbers — reach, impressions, follower activity graphs — are platform
metrics computed over your content, not files in your account's export. What the
archive does hold is the behavioural record underneath: likes you gave and received
where recorded, comments, saves, the activity files this site's activity post maps
file by file. The distinction that matters when reading your own numbers: a count of
events that happened is the export's language; a rate, reach or impression total is
the platform's derived dashboard, and derived dashboards were not part of what you
requested.

There is one more wrinkle worth stating honestly: your own posts' totals also inherit
the deletions from item 1. A post removed before the request takes its engagement
history with it, so any long-horizon total you assemble from an archive is a total of
what survived — deletions included as holes, not zeroes. A trustworthy tool marks the
holes; it does not average over them as if nothing happened.

When re-requesting helps, and when it never does

The split at the top of this post decides the question every time:

• Structural absence (recent period not yet included, folder not selected in your

  request format) — a new, complete, properly formatted request helps. That is the
  other post's subject, and its answer is yes.

• The eight here — a new request copies the same present state. Recently-deleted

  items may shift as the platform's own window advances; everything else is identical,
  because you are re-snapshotting a state that already excludes them.

The test to apply to any "get it back" claim: does the thing still exist anywhere on
the account now? If yes, the question is a request/settings question (see the
request post's format section). If no — deleted long ago, unsent, expired, someone
else's record — no archive of yours contains it, and the honest answer is the no this
post has given eight times.

What a trustworthy tool does with eight absences

A tool reading your archive cannot recover any of the eight, and its honesty is
measured by what it does instead: render is_unsent as a visible marker rather than
dropping the row; keep recently_deleted_content in its own bucket rather than
mixing it into your live posts; report a relationship list's emptiness as ambiguous
rather than as "you blocked nobody" when the folder was absent from the ZIP; and
show completeness warnings when a file that should exist did not arrive. Each of
those behaviours is this codebase doing the substitute column of the table above —
showing what is real, naming what is missing, inventing nothing.

Questions this brings up

This post is the taxonomy; its siblings answer the individual itches: the
five-questions post for the impossible questions in depth, the missing-half post for
the absence a re-download can fix, and the messages post for how unsent rows behave
inside a thread. If a claim here ever disagrees with a folder in your own archive,
believe the archive and write to us — every file named above was parsed from real
export structures by the code cited.

¹: packages/shared/src/parsers/content.ts — recently_deleted_content/*.json
and recently_deleted_content.json are collected into a recentlyDeleted bucket,
separate from posts, reels and stories, and kept distinct through the HTML
fallback and merge stages too.
²: This site's own request guide, under the deleted-and-unsent line: a deletion is
the end of the record; deleted and unsent messages are not in the export, and no
re-request changes that.
³: packages/shared/src/parsers/messages.ts — msg.is_unsent maps the type
to unsent; isUnsent is carried on the parsed message; the renderer displays
"Message unsent" rather than inventing or silently dropping a body.
⁴: The export's stories/ area (archived and highlighted stories) plus the
activity files stories_viewed.json, story_likes.json and story sticker
interactions; viewer lists are never part of the account's exportable records — see
this site's FAQ and the five-questions post.
⁵: packages/shared/src/parsers/connections.ts — blocked_profiles.json /
blocked_accounts.json are matched (JSON and HTML variants) into the blocked
relationship list; this site's folder-by-folder map lists
connections/blocked_profiles.json as "accounts you blocked".