Guides · 28 Aug 2026 · 3 min read
The Weird Quirks in Your Tinder and Hinge Exports, Actually Explained
The file you download is not a tidy spreadsheet
You requested your data, waited, and got an email with a link. Inside the zip: JSON files named things like matches.json and account.json, or one big data.json from Tinder. That's the raw material RizzStats' extractor reads in your browser to build your match rate, reply rate, activity timeline, streaks, and Rizz Score.
Most of the time the file behaves. When it doesn't, the reason usually traces back to something specific about how Tinder and Hinge build these exports. Here's what's going on, and what to do about each case.
Hinge's export clock is real, and it's short
Hinge's help center is specific: once your data is ready, you get 48 hours to grab it before the link expires and you have to resubmit. The request itself can take up to 30 days to process, though most people report it landing faster.
That combination catches people out. You request the export, forget about it, finally open the email a day and a half later, and the link is dead. If your upload to RizzStats fails on the download step rather than while parsing, that's the first thing worth checking: request again, and grab the file inside the window this time.
Why Hinge match timestamps can look "off"
Hinge's raw timestamps arrive as plain strings like 2026-03-14 22:10:00, with no timezone attached. RizzStats parses these as UTC on purpose, so extracting the same file twice always produces the same result regardless of where the parsing happens.
The practical effect: match someone at 11pm in a timezone well behind UTC, and that interaction can land on the next calendar day in your activity timeline and streak count. Nothing's broken; it's a direct consequence of Hinge not shipping timezone data at all. If a streak or a day's activity looks off by one from what you remember, this is almost always why. Tinder doesn't have this issue, since its usage data is already bucketed by day.
Hinge doesn't give matches an ID. RizzStats builds one.
Tinder tags every match with a match_id. Hinge's file has no match identifier at all, just a list of interactions with likes, matches, chats, and "we met" answers attached. To keep your match history stable across re-uploads, RizzStats derives an id from each interaction's earliest event timestamp, with a tie-breaker for the rare case where two land in the same second.
You'll never see this id in the product, but it's why re-uploading a newer Hinge export months later lines up cleanly with what's already on your dashboard instead of duplicating everything, something a simple array position couldn't guarantee since Hinge doesn't promise stable ordering between exports.
When RizzStats just rejects the file
If your export has zero recorded usage and zero matches, RizzStats won't ingest it. That's a deliberate guard, not over-caution: the schemas are loose enough to technically accept a near-empty file and quietly build a blank profile instead of flagging the problem. An empty dashboard with no explanation is worse than an upfront rejection.
If you hit this, check three things: you grabbed the actual data file from the zip and not a summary or HTML copy; the account genuinely has usage or matches to report (a brand-new, never-opened account won't); and the export itself isn't corrupted, in which case re-requesting produces a fresh one.
One thing worth knowing before you request either export
Message text you sent is always read to build your Rizz Score and reply rate; there's no version of those metrics without it. Bio and city are things you choose to include at the upload step, not fields pulled in automatically. None of that touches what Tinder or Hinge put in your export file, only what RizzStats keeps once it's parsed in your browser. Knowing what's actually inside that zip makes a rejected upload or an off-by-a-day streak a lot less mysterious the second time around.