429 / 503 · Retry-After · X-RateLimit
Got a 429?
When can you retry?
Paste the response headers and get the exact answer: the absolute retry-at time in your local
zone, a live countdown, quota remaining, and what every header means. It untangles the classic confusion —
is x-ratelimit-reset epoch seconds, milliseconds, or a countdown? Is Retry-After seconds or a date?
Everything runs in your browser.
What it shows
One paste, three answers
When can I retry
The absolute retry time in local + UTC and a live countdown — from Retry-After if present, otherwise the reset header.
Epoch vs delta, solved
Auto-detects whether *-reset is epoch seconds, epoch milliseconds, or seconds-until-reset — and shows which it used, with a manual override.
How much quota is left
Reads limit / remaining / used and shows the remaining-percentage bar.
Every dialect
Handles X-RateLimit-*, the legacy RateLimit-*, the new IETF combined RateLimit + RateLimit-Policy, and GitHub / Twitter-X / Discord / GitLab variants.
Per-header explainer
A plain-English line for each header you paste — so you also learn what it means, not just the number.
Nothing leaves your browser
100% static page, pure client-side JavaScript. No backend, no upload, no logs.
Open methodology
Every rule, in the open
No mystery score. Here is exactly how each value is interpreted — so you can verify and trust the result.
- Retry-AfterRFC 9110: a bare integer is delta-seconds (wait N seconds); anything else is parsed as an HTTP-date. Converted to an absolute retry time. Never treated as epoch.
- *-Reset magnitude heuristicFor x-ratelimit-reset / ratelimit-reset: value ≥ 1e12 → Unix epoch milliseconds; ≥ 1e9 → Unix epoch seconds (≈ year 2001+); smaller → delta-seconds (a countdown). The chosen interpretation is always shown, with a manual override.
- *-Reset-Afterx-ratelimit-reset-after and similar are always delta-seconds relative to the response time.
- Reset HTTP-datex-ratelimit-resettime / RateLimit-ResetTime are parsed as absolute HTTP-dates.
- IETF combined RateLimitThe single RateLimit header is parsed for limit / remaining / reset (both "limit=, remaining=, reset=" and the "r=, t=" short forms); reset is treated as delta-seconds.
- QuotaLimit / Remaining / Used are read from the X-RateLimit-* or RateLimit-* family; remaining % = remaining ÷ limit.
- HeadlineRetry-After wins the headline retry time when present; otherwise the first resolvable reset value is used. All detected headers are listed regardless.
One caveat, stated plainly: delta values (Retry-After: 60,
x-ratelimit-reset-after, and small reset numbers) are relative to when the server sent the response. This
tool assumes “now” is when you paste — the best a header-only tool can do. Absolute formats (epoch and HTTP-date) are exact.
Frequently asked questions
What does ratelimitlens do?
Paste the raw response headers from a 429 / 503 (or any response) and it tells you the exact absolute time you are allowed to retry — in your local time and UTC — with a live countdown, how much quota is left, and a plain-English explanation of each rate-limit header. Everything runs in your browser; nothing is uploaded.
Is x-ratelimit-reset epoch seconds, milliseconds, or seconds-until-reset?
It depends on the vendor — which is exactly the confusion this tool resolves. GitHub, Twitter/X and GitLab use Unix epoch SECONDS; some APIs send epoch MILLISECONDS; the IETF RateLimit header and headers like x-ratelimit-reset-after use DELTA seconds (a countdown). ratelimitlens auto-detects by magnitude (≥1e12 → ms, ≥1e9 → epoch seconds, otherwise delta seconds) and shows which it used. If it guesses wrong, a one-click toggle lets you force the format.
How is Retry-After interpreted?
Per RFC 9110, Retry-After is either a number of seconds to wait (delta-seconds) or an absolute HTTP-date — never an epoch timestamp. ratelimitlens handles both and converts them to an absolute retry time and countdown.
Which header wins when several are present?
Retry-After is the server’s explicit “wait this long” instruction, so it headlines the retry time. If there is no Retry-After, the reset header (x-ratelimit-reset / RateLimit reset / reset-after / a reset HTTP-date) is used instead. Every header found is still shown in the breakdown.
Why might the countdown be slightly off?
Delta values (Retry-After: 60, x-ratelimit-reset-after: 60, and small reset numbers) are relative to when the server sent the response — not when you pasted. The tool assumes “now” is paste time, which is the best a header-only tool can do; absolute formats (epoch and HTTP-date) are exact. This is stated in the result.
Does it support the new IETF RateLimit header?
Yes — it reads the combined RateLimit header (limit / remaining / reset, including the r= and t= short forms) and RateLimit-Policy, as well as the legacy separate RateLimit-* and the X-RateLimit-* family used by GitHub, Twitter/X, Discord, GitLab and others.
Is my data safe?
Completely — this is a static page and all parsing happens in your browser with JavaScript. No headers are ever sent to a server, there is no backend, and nothing is logged.