API Rate Limit Header Parser
Interpret current and provider-specific rate-limit headers without guessing ambiguous reset semantics.
Paste headers from curl, browser DevTools, Postman, an API client, or gateway logs. The parser runs locally in your browser.
Options
The reset-format choice applies only to legacy or provider-specific reset values. Current draft RateLimit t values are seconds.
Output
Parsed API rate limit output will appear here.
Rate-limit headers are not one universal format
APIs expose quota information in several incompatible ways. The current IETF HTTPAPI work is centered onRateLimit andRateLimit-Policy structured fields, while many deployed APIs still use older RateLimit-* or X-RateLimit conventions.
That difference matters most for time values. In the current draft, the tparameter is an effective window in seconds. X-RateLimit-Reset has no single cross-provider meaning, so the parser will not silently guess a provider-specific reset format when it is ambiguous.
What the parser derives
Current draft fields can expose a policy identifier, allocated quota, available quota, and effective window. Older split fields can expose limit and remaining values directly. Retry-After is handled separately because it can be either delay-seconds or an HTTP date and takes precedence over quota-window hints when a server asks the client to wait.
Provider-specific reset values need an explicit choice
Some X-RateLimit APIs use Unix seconds, others use a delay, and some publish a date-time. Auto mode recognizes GitHub-style epoch resets when the resource field identifies that convention; otherwise an ambiguous numeric reset stays unresolved until you choose its format.
A remaining value is a hint, not a promise
A positive remaining quota does not guarantee that the next request will succeed. Servers can apply several limits, change capacity dynamically, or throttle for reasons not represented by these fields. Treat the numbers as input to conservative scheduling rather than permission to consume the quota as fast as possible.
Sensitive response metadata
Parsing happens in the browser, but pasted header dumps can still contain request identifiers, account-specific quota names, cookies, authorization data, or internal gateway metadata. Remove unrelated secrets before sharing copied output.
Standards and live specification status
Retry-After semantics come from RFC 9110, and HTTP 429 is defined by RFC 6585. The newer RateLimit / RateLimit-Policy design is still an active IETF Internet-Draft, not a published RFC, so its syntax can change before standardization. Follow the current HTTPAPI draft.
Questions that affect retry code
Why is my X-RateLimit-Reset value not converted automatically?
Because that field is provider-specific. A numeric value can mean epoch seconds or a delay, so guessing can produce a dangerously wrong retry time.
Should Retry-After override a RateLimit window?
When both are present, follow Retry-After for the requested wait. Quota fields can still help shape the request rate after that delay.
Does a parsed quota prove how the server will throttle me?
No. The server remains authoritative, and multiple or dynamic quota policies can affect later requests.