Rate Limiter Algorithm Simulator

Send the same request timeline through five classic rate limiters — token bucket, leaky bucket, fixed window, sliding window log, sliding window counter — and watch which requests each one allows or rejects, side by side. Great for picking the right algorithm for an API or DDoS filter.

Algorithms

Token bucketRefills at r/s, burst = capacity

Leaky bucket (queue)Constant output rate, buffered burst

Fixed windowCounter resets every window

Sliding window logExact, keeps every timestamp

Sliding window counterPrev + current weighted average

Parameters

Limit (requests / window) Window (seconds) Bucket capacity (token/leaky) Refill / drain (per sec)

Request timeline

One timestamp per line, in seconds since the start. Or use a preset.

Duration (seconds)

0 requests total

Result

allowed rejected

Algorithm	Allowed	Rejected	Reject %	Notes

How each algorithm works

Token bucket holds up to capacity tokens, refilled at refill per second. Each request pulls one token; empty ⇒ reject. Allows bursts up to the full bucket then throttles to the refill rate.
Leaky bucket (queue) puts requests in a bounded queue that drains at a constant rate. Overflow rejects. Smooths bursts into a steady output but adds latency.
Fixed window keeps one counter per window. Simple and O(1), but can allow 2×limit across a window boundary.
Sliding window log stores every request timestamp and prunes those older than one window. Exact, but memory grows with traffic.
Sliding window counter keeps the previous and current window counters and weights the previous by the fraction of the sliding window it still covers — a common O(1) approximation used by Cloudflare, Redis, and Kong.