Facebook Friend List Comparison Between Two Saved Snapshots

The comparison happens locally in your browser using information you supply. It does not sign in to Facebook, retrieve friends, visit profiles, or identify who ended a friendship. Facebook has snapshot mode here, not a Following versus Followers mode. You need two comparable records; a single download cannot reconstruct an earlier friend list that you never saved. The result is a record comparison, not an account investigation or a measure of how people feel about you.

Define One Friend List and One Comparison Period

Start with the Facebook profile whose friends you are reviewing. Write down that profile, the two collection dates, and what each source represents. Friends of your personal profile are not interchangeable with Page followers, people who liked a post, group members, or event responses. Even when several groups contain familiar people, their membership answers different questions. Combining them produces differences that have nothing to do with the friend list.

Our example is a ceramics workshop host who keeps a monthly record of their own Facebook friends. They want to understand how the recorded network changed around a community open day. The comparison can show which identifiers newly appear or disappear between those records. It cannot show whether an attendee bought a class, read an announcement, or became a friend because of the event. Those claims need separate records.

Keep the same inclusion rule on both dates. If the earlier file represents current friends, the later file must also represent current friends. Do not add deleted friends, blocked accounts, pending requests, or suggested contacts to either side. A historical category is not a substitute for a missing current list. If you deliberately track a subset, such as a manually maintained workshop contact group, label it as that subset rather than all Facebook friends.

Dates identify your observation points, not exact friendship events. A record saved on September 1 and another saved on October 1 leave an interval between them. Someone might leave and return within that interval and appear in both files. Conversely, a profile absent from the second file has no event timestamp attached merely because you entered October 1. Keep the collection method with the dates so future comparisons have the same meaning.

Inspect the Export Before Preparing Identifiers

Meta places its information access and download controls in Accounts Center, which you can reach through Facebook settings. Look for the information export or download option available to your account, select the intended Facebook profile, and review the categories offered. Interface wording can change. The important step is selecting the correct account and inspecting what the resulting material actually contains, rather than assuming every connection record is a current friend.

An official download is source material, not a ready input contract for this checker. Extract an archive locally before inspecting its files. The checker does not accept ZIP archives or HTML pages and does not provide a guaranteed Facebook archive extractor. A file with a familiar title can still contain nested objects, names without identifiers, or several relationship categories. Opening it successfully on your computer does not make it directly comparable.

Prepare a clean list from the relevant current-friend records only when their identifiers are available. Supported choices are one identifier per line in TXT, an identity column in CSV, or a prepared JSON array of identifier strings. If a native JSON export contains complex records, isolate the profile URL or ID field into that supported shape first. Do not rename the extension and expect the structure to change.

Inspect both sources independently. Check the category, the account, and whether the collection is complete for your stated purpose. An export date range should not be treated as a command to recreate the full friend list on an arbitrary past day. If the data does not supply a reliable current-friend list or usable identifiers, stop that comparison. Keep the limitation in your notes and establish a trustworthy baseline when you can.

Use Profile URLs or IDs Instead of Names

Facebook matching in this tool uses canonical profile URLs or explicit numeric identifiers with the id: prefix. Choose a consistent identity representation for both snapshots. A prepared ID entry might look like id:100000000000001; this is an illustrative format, not a verified account. Keep IDs as text during preparation so a spreadsheet does not round long numbers or convert them into a different representation.

Never compare display names as though they were account keys. Two people can share a name, and a person can change the name shown on a profile. Emails and your own contact labels are not reliable substitutes either. A row that contains only a name is unresolved for this workflow. Leave it in a separate preparation note rather than inserting a guessed profile URL into the comparison.

Use actual profile URLs, not links to posts, photos, groups, Pages, or search results. Preserve the part of a URL that identifies the profile when preparing your files. The checker normalizes recognized Facebook profile URLs, but normalization is a text-matching process. It does not visit the destination, test whether it is available, or discover that an old profile address now refers to the same person under another address.

A numeric ID in one file and a profile URL in the other should not be assumed to match. If you already have reliable evidence connecting the two representations, prepare both snapshots consistently outside the tool and retain the original files. Without that evidence, keep the uncertainty visible. Similar names, photos, or address fragments are not enough for an automatic merge, especially when the comparison will guide a community contact review.

Load the Earlier and Later Sources Carefully

Choose Facebook and snapshot mode before entering the lists. Put the older record in source A, Earlier list, and the newer record in source B, Later list. Add optional dates in chronological order if you know them. The dates describe the files; they do not fetch data. Swapping the sources reverses the added and absent buckets, so verify the source labels before interpreting any result.

Paste prepared identifiers or select supported local files for each side. When using a CSV with several columns, explicitly select the identity column. For example, a preparation sheet might contain profile identifier, local note, and collection date. Only the identifier belongs in matching. A date or name column can look tidy while representing the wrong information, so check a few selected values before accepting the comparison.

Review invalid entries and duplicate counts before the headline totals. Duplicates inside a source count once after cleanup; rejected entries do not become accounts. In the workshop example, the earlier preparation has 248 candidate rows: five duplicates and three invalid entries leave 240 unique valid identifiers. The later preparation has 264 candidate rows: four duplicates and two invalid entries leave 258. Compare those cleaned totals, not the original row counts.

A blank box does not establish that a friend list is empty. Mark a source intentionally empty only when you have confirmed that an empty list is the actual source you mean to compare. Missing files, failed extraction, or a category containing no usable identifiers are not that confirmation. Resolve source errors first, and rerun after corrections so you do not interpret or export an outdated result.

Read the Workshop Example Without Losing the Arithmetic

The host compares 240 earlier identifiers with 258 later identifiers. The checker finds 228 present in both, 12 absent from the later list, and 30 added to the later list. The earlier total reconciles as 228 plus 12, or 240. The later total reconciles as 228 plus 30, or 258. These checks are useful because each bucket must agree with the two source totals after cleanup.

The net increase is 18 identifiers: 30 added minus 12 absent. Relative to the earlier total, that is 18 divided by 240, multiplied by 100, or 7.5%. Calling the result 30 new friends would ignore the missing entries and overstate the net change. Calling the net increase of 18 the complete amount of movement would also miss the fact that 42 identifiers appear in only one snapshot.

The three disjoint buckets contain 270 distinct identifiers across the pair: 228 plus 12 plus 30. That is the union of the two records, not the later friend count. The bar chart compares those three groups. Do not read its total as 270 current friends or sum both source totals to claim 498 different people; identifiers shared by the snapshots appear in both source counts.

You can describe 228 out of 240 earlier identifiers as present again, giving 95% recorded overlap with the earlier list. That statement is about the supplied records, not continuous friendship retention or engagement. The host uses the 30 added entries as a review queue for their own notes, while the 12 missing entries receive a source and identity check. Neither group becomes an automatic invitation or removal instruction.

Investigate Missing Entries as a Data Question First

Absent from later list means exactly that the earlier identifier did not match a later identifier. It does not establish who clicked Unfriend, whether someone blocked anyone, or why a relationship changed. An unavailable account, changed profile address, incomplete capture, different category, or preparation error can require separate investigation. The tool cannot choose among explanations because it has no live account evidence beyond your two text sources.

Check for broad patterns before checking individual entries. If most missing rows come from one file, confirm that the file was included on the correct side and its identity column was selected. If the later record is much smaller than expected, revisit collection completeness. If all older entries use IDs and newer entries use URLs, fix that representation mismatch before attributing the difference to a social event.

Then review uncertain identities in your own source records. Keep a note when a profile address changed and you have independent evidence linking the records. Do not silently rewrite the earlier source just to make the report look stable. Preserve the original comparison and, when useful, a clearly labeled corrected run. That separation lets another reviewer understand whether the difference came from identity preparation or from the records themselves.

Avoid using a missing entry as a reason to send an accusatory message. There is no interpersonal conclusion in the bucket label. For the workshop host, a useful follow-up is checking whether a known contact remains in their separate booking or conversation records. A person can be an important customer without appearing in a particular friend snapshot, and a familiar identifier can remain in both lists without any recent conversation.

Turn the Review into Better Community Planning

The workshop host keeps friend-list review separate from event attendance. The 30 added identifiers do not become 30 attendees, leads, or buyers. The host looks at their own notes to see whether any changes coincide with introductions at the open day, while leaving entries with no evidence unassigned. This produces a useful question for the next event without claiming that the friend-list difference proves which activity caused it.

A second useful scenario is a handover between two people helping manage the same community project. A dated comparison can explain why an older contact worksheet and a newer worksheet no longer agree. Keep the account identity and inclusion rule attached to the report, and distinguish resolved preparation issues from unresolved missing entries. The report supports discussion of the records; it is not a live directory of everyone the project can reach.

When the real question concerns presentation, use the social media profile audit alongside your own observations. A clearer profile can support a community effort, but this checker cannot tell you who viewed a bio or noticed a change. Keep that qualitative review distinct from the identifier counts. You will then know which conclusions came from a list comparison and which came from inspecting the profile.

For a paid workshop, bookings and campaign costs belong in the social media ROI calculator, using your actual financial records. Do not assign a ticket value to every added friend or treat every absent identifier as lost revenue. Choosing the right measurement keeps the friend comparison useful: it documents recorded network changes while the booking ledger answers whether the event paid for its work.

Save a Reproducible Report and Keep Automation Separate

Select a result bucket and search when you need to inspect particular identifiers. Results are sorted, not arranged by friendship date or importance. Pagination shows 50 rows at a time without shrinking the full counts. Copy the selected list for a focused review, or export the full categorized CSV when you need the complete comparison. A search view is not a new definition of the original two source lists.

The PDF is an aggregate report with the chart, input and cleanup counts, context, and optional dates; it does not include raw identifiers. CSV and copied lists do include identifiers. Choose the output that matches the review: a summary for planning, or a detailed file for checking particular records. Save the source files and your preparation notes separately because the checker does not persist your comparison for the next monthly review.

Create the next baseline with the same profile, category, identity representation, and collection method. Compare October with November rather than quietly replacing September in an old report. If the method changes, explain that change before interpreting a sudden jump. A routine with clear source records is more useful than frequent checks based on inconsistent lists. You can revisit earlier comparisons because their inputs remain documented outside the tool.

For ongoing Facebook work, SMTasker Facebook automation supports Like, Comment, and Publish through native Android apps, with a Windows or macOS client. Those are separate workflows from this browser checker. The checker does not connect to SMTasker, import results into it, confirm live accounts, or perform friendship actions. Use the comparison for review, then assess supported automation against the publishing and engagement work you actually need.

Questions about Facebook Friend Lists

Continue with another list guide

Return to the Follower & Connection List Checker to compare your prepared data, explore a related guide below or browse all free tools.