There Is No Single Rate-Limit Header Standard
If you've integrated more than two or three third-party APIs, you've probably noticed their rate-limit headers don't agree with each other. That's because there isn't one standard — there are at least three conventions in wide use, and they don't even agree on what the "reset" number means.
Convention 1: GitHub-Style X-RateLimit-*
Popularized by GitHub's REST API and copied by dozens of others, this convention uses X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. The Reset value here is almost always a Unix epoch timestamp in seconds — the absolute moment the window resets, not a countdown.
Convention 2: The IETF Draft Standard
The IETF has a draft specification for RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset (no "X-" prefix, since IETF-standardized headers don't use it). Critically, this draft defines Reset as seconds until the window resets — a relative count, not an absolute timestamp. Mixing this up with the GitHub convention is an easy way to compute a "reset" time that's decades in the future or the past.
Convention 3: Retry-After
Retry-After is an actual RFC 7231 standard header, not rate-limit-specific — it also shows up on 503 responses during maintenance windows. It can be either an integer number of seconds, or a full HTTP-date string like Wed, 21 Oct 2026 07:28:00 GMT. Code that assumes it's always a number will throw on the date form.
The Easiest Way to Tell Epoch From Relative
If you're writing a generic parser and don't know which convention a given API uses, magnitude is your friend: the current Unix epoch in seconds is roughly 1.7-1.8 billion right now, and climbing by about 31.5 million a year. Any realistic rate-limit window — minutes, hours, even a full day — is nowhere close to that. So a threshold like "greater than one billion means it's an epoch timestamp" is a safe, simple heuristic that works for any rate-limit window you'll realistically encounter for the next few decades.
Debugging This Faster
Instead of writing this parsing logic from scratch every time you hit a new API, the API Rate Limit Header Parser does it for you: paste the raw headers, and it identifies the convention, decodes the Reset value correctly, and shows a plain human countdown.
- Paste headers copied from your browser's network tab or a curl -i output.
- See limit, remaining, and a resets-in countdown for whichever convention is present.
- Cross-check Retry-After separately, since it can appear alongside either convention.
Everything runs locally in your browser — no headers are ever sent anywhere.
Frequently Asked Questions
It checks the magnitude of the number. Current Unix epoch time is in the 1.7-1.8 billion range, while realistic rate-limit windows (minutes to a day) are always far smaller — so any value over one billion is treated as an epoch timestamp, and anything smaller is treated as relative seconds.
Yes — Retry-After can legally be either an integer second count or a full HTTP-date like "Wed, 21 Oct 2026 07:28:00 GMT" per RFC 7231, and the tool detects and parses both correctly.
Yes — the API Rate Limit Header Parser does exactly this, converting raw header values into a plain-English countdown and wall-clock time. It's a one-time $4.99 purchase — no subscription, no account required.
Yes — the parser scans every line for a colon-separated header and only acts on the ones it recognizes, so pasting a full response header dump works fine.
No — it only parses text you paste in. It never calls any API on your behalf, so it can't accidentally consume any of your remaining rate-limit quota.