Inside the Instagram Data ZIP: Dissecting followers and following With Real Files

1. Where the relationship files are, and why their names vary

In a Korean-language export the relationship files are usually found under connections/followers_and_following or its translated equivalent. But Meta can rename folders, and selecting "all information" may place them deeper, so CheckMate checks the tail of each ZIP entry path together with a list of known candidates. It does not stop at followers_1.json; it merges every numbered followers file.

The two relationship files can also be shaped differently. There are older followers files that begin directly with an array, and following files where the array sits under an object key named relationships_following. Some newer exports use label_values and fbid. Code that "casts both to the same type" tends to miss one of them.

connections/
└── followers_and_following/
    ├── followers_1.json
    ├── followers_2.json   # present on some accounts
    └── following.json

2. The fields actually read from a single person entry

An old-style string_list_data entry has title, value, href and timestamp, together or only some of them. There are cases where title and value look like a previous name while the username taken from href looks like the current one, but that alone cannot confirm a username change: neither the generation time of the data nor how the fields are refreshed is guaranteed by any public contract.

In some newer entries an fbid was observed as a numeric-string account identifier. When both lists provide the same fbid it is the strongest key for linking a relationship even if the username differs. It is absent from older files, though, so the service description must not be rewritten as "100% tracking by unique ID". displayName is never used as a matching key because different people can share it.

{
  "title": "sample_old_name",
  "string_list_data": [{
    "href": "https://www.instagram.com/_u/sample_name",
    "value": "sample_name",
    "timestamp": 1700000000
  }]
}

3. 2,794 days is neither a "complete data guarantee" nor a "365-day limit"

The observed range is the latest valid timestamp minus the earliest, divided by 86,400 seconds and truncated to whole days. That the real ZIP produced 2,794 days for followers and 2,783 for following means records exist across that span. It does not mean every date is covered or that every past follower from that period is included.

An earlier version used a heuristic that treated followers as truncated when following exceeded 400 days but followers fell below 400, plus a ratio rule that flagged followers below 30% of following as suspicious. Real ratios differ by account type, and the supplied ZIP contradicted the 365-day assumption. Both rules were removed in the Recovery Release.

The current partial-file check is used only when the actual follower count can be read from a separate audience insight. When the number of followers entries in the file is at least 10% below that actual count, a re-download prompt is shown. The exact 10% boundary is tested too. Without an actual count, neither the span nor the following ratio is used to declare that the file "is not all time".

4. Mutuals and not-following-back are set comparisons, but the identifier is everything

The basic rule classifies accounts that are in following but not in followers as "accounts that currently do not follow me back". Accounts only in followers are "fans", and accounts in both are mutuals. Because this compares a snapshot taken when the export was generated, it does not tell you "who unfollowed me yesterday". Real changes require comparing two different snapshots.

Identity matching prefers fbid when present; otherwise the username extracted from href, plus the title and value candidates, are lower-cased and compared. When the identifiers within one entry disagree, the result may carry a "possible username change" badge, but deactivation, deletion and re-registration cannot be told apart.

• Current not-following-back: identifiers present in following but absent from followers
• Fans: identifiers present in followers but absent from following
• Mutuals: entries with the same fbid, or compatible username identifiers, on both sides
• Actual unfollow changes: the result of comparing two ZIPs from different dates with snapshot compare

5. Edge cases the parser must handle

For a JSON parser, isolating failures per section matters more than handling well-formed files. A change in the ads information format must not wipe out the relationship results, and one unknown field must not fail the whole ZIP. CheckMate records each insight's parse error and keeps showing the remaining results.

There are double-encoding cases where Korean labels look like mis-decoded latin1. They are reinterpreted only when they form a valid UTF-8 byte sequence; text that is already proper Unicode, or that fails to decode, is kept as-is. Timestamps can mix seconds, milliseconds and microseconds, so they are normalised to seconds based on magnitude.

• Merge every followers_N split file regardless of numeric order and normalise duplicates.
• Find the real label_values array that comes after an empty media array.
• Exclude timestamps of 0, negative values and NaN from the observed range.
• Never use display names as relationship keys because of the false-match risk.
• Degrade unknown sections to null instead of failing the relationship analysis with them.

Sources and how they were verified

• Meta Newsroom — Download Your Information moves into Accounts Center — Confirms the official location of the export feature.
• Instagram Help Center — Export a copy of your information — The official reference for the export feature itself. The file schema was verified separately by observing real ZIPs.
• CheckMate Terms of Service — result accuracy and limits — Discloses the current not-following-back rule, identifier mismatches, and file-time limits.

Frequently asked questions

Read next