All 10 Instagram export files opened
— where fbid is, and where it isn't
CheckMate operator · Published · Data: export requested 2026-08-18 · Sample: the operator's own account, one account only
It is well known that Instagram has been changing the format of its data export. What I could not find anywhere was a list of which files inside a single ZIP use the new format and which still use the old one. So I opened all ten files in connections/followers_and_following/ and counted entries, format, and whether each entry carries the account's permanent ID (fbid). The conclusion is simple and slightly inconvenient: the only two files an unfollower check needs are the two without an fbid.
Summary (export of 2026-08-18, one account)
- Of 10 files, 8 use the new format (label_values + fbid); all 993 of their entries have an fbid
- Only followers_1.json (543) and following.json (565) use the old format (string_list_data): zero fbids
- Both formats coexist in one ZIP, produced by one request on the same day
Results per file
| File | Entries | Format | fbid |
|---|---|---|---|
| followers_1.json | 543 | old (string_list_data) | none |
| following.json | 565 | old (string_list_data) | none |
| removed_suggestions.json | 893 | new (label_values) | all 893 |
| close_friends.json | 71 | new (label_values) | all 71 |
| hide_story_from.json | 12 | new (label_values) | all 12 |
| recently_unfollowed_profiles.json | 8 | new (label_values) | all 8 |
| recent_follow_requests.json | 5 | new (label_values) | all 5 |
| blocked_profiles.json | 2 | new (label_values) | all 2 |
| restricted_profiles.json | 2 | new (label_values) | all 2 |
| follow_requests_you've_received.json | 0 | (empty) | — |
Each file was parsed as JSON and the length of the top-level array (or, for a wrapper object, its first array) was taken as the entry count. An entry with a string_list_data key was classified as old format and one with a label_values key as new format. No entry had both keys.
What the two formats actually look like
Old format: one entry from followers_1.json
{
"title": "",
"media_list_data": [],
"string_list_data": [
{
"href": "https://www.instagram.com/example_user",
"value": "example_user",
"timestamp": 1786714026
}
]
}The only identifiers are value (the username) and href (the profile URL), and both are derived from the same username. following.json differs only in that the username sits in title, there is no value, and the href takes the /_u/username form.
New format: one entry from recently_unfollowed_profiles.json
{
"timestamp": 1786438546,
"media": [],
"label_values": [
{ "label": "URL", "value": "https://linktr.ee/..." },
{ "label": "ì´ë¦„", "value": "..." },
{ "label": "ì‚¬ìš©ìž ì´ë¦„", "value": "atwosomeplace_official" }
],
"fbid": "17841403294706765"
}The garbled labels are the file's own doing: UTF-8 bytes written as if they were latin1 (decoded, they read "Name" and "Username" in Korean). What matters is the last line, fbid. That value is a permanent account number that does not change when the username changes.
Why this difference decides username-change tracking
An unfollower check boils down to one question: is account A, which I follow, also in the list of accounts that follow me? If the only comparison key is the username, then the moment A changes it, A looks like two different people across the two lists. With an fbid you can link them regardless of the username. CheckMate's parser is in fact built to use fbid as the primary key when it is present (src/lib/analyzer.ts).
The problem, as the table shows, is that the followers and following files have no fbid. Consequently:
- An account that changed its username cannot be confirmed as the same person from the file alone. That holds for every tool, not just this one.
- In old-format entries, value/title and href come from the same username, so comparing them to detect a "change" always matches by construction. Any claim that this comparison catches renames in these files is incorrect.
- This is why CheckMate labels such accounts as a possible username change and never issues a definitive verdict. Deactivated and deleted accounts are indistinguishable from the file for the same reason.
Check it yourself
import json, os
B = 'connections/followers_and_following/'
for fn in sorted(os.listdir(B)):
d = json.load(open(B + fn))
items = d if isinstance(d, list) else next(v for v in d.values() if isinstance(v, list))
old = sum('string_list_data' in it for it in items)
new = sum('label_values' in it for it in items)
fbid = sum(bool(it.get('fbid')) for it in items)
print(f'{fn:40} n={len(items):4} old={old:4} new={new:4} fbid={fbid:4}')Unzip the export and run the script from the directory that contains connections; the output has the same columns as the table above. Uploading to CheckMate runs the same parser, but since the file never leaves your browser, a local script is the faster way to inspect the structure itself.
Things I learned along the way
- removed_suggestions.json is the largest file at 893 entries. Every account you ever dismissed from "Suggested for you" is kept, fbid included.
- recently_unfollowed_profiles.json lists the 8 accounts I recently unfollowed. It is not a list of people who unfollowed me; the name misleads people constantly.
- In the new format timestamp sits at the top level of each entry; in the old format it lives at string_list_data[0].timestamp. Both were unix seconds.