Privacy

What this endpoint keeps about a request, and what it never does.

The promise

Uploads are processed in memory, never written to disk, and not retained. The compressed result is returned in the response and then discarded.

That sentence is this API’s whole privacy model, and it’s checked, not just asserted. A CI gate (apps/api/scripts/check-no-persistence.mjs) runs on every pull request and every push to main, and it checks two different things with two different strengths:

• The config, structurally. wrangler.jsonc is read against an allowlist of the twelve top-level keys this Worker actually uses. Any other key — R2, D1, Queues, Analytics Engine, Pipelines, Workflows, or a binding type Cloudflare invents next month — fails the build merely by being declared, because it is not on the list, not because someone remembered to name it. The two bindings that are allowed must be exactly kv_namespaces: { API_KEYS } and durable_objects: { RATE_LIMITER } bound to exactly the class RateLimiter; a second, renamed, or extra entry in either — or the one allowed binding repointed at a different class — fails too. That Durable Object is the per-key rate limiter, and it is the one vetted exception on this list: it keeps a request count and a window start in memory, never calls ctx.storage, and never sees an uploaded byte. It replaced Cloudflare’s rate-limiting binding, which was measured allowing every request it was asked about. Nothing a call site does can get around this half: wrangler never provisions a binding the config doesn’t declare, so there is no storage surface for clever code to reach.
• The deployed bundle, textually. The gate also scans dist/index.js — the exact bundle wrangler would deploy — for write calls on any env.* binding (bare, aliased, or destructured) and for any use of the Workers Cache API. This half is a text scan over compiled JavaScript, not a parser with scope and data-flow analysis, and the script’s own header says so: computed access, a binding embedded in an object literal, a compound assignment, and genuine cross-module data flow are gaps it does not close. It is a real check, not a proof.

The conclusion rests on the first half, which is why it holds: there is no code path in this Worker that could persist an image even by accident, because there is no storage surface for it to persist to.

A separate product from the website

Image KB Reducer also offers a command-line tool and this HTTP API for developers, documented here at docs.imagekbreducer.com. They are not imagekbreducer.com, and that site’s own privacy policy is about that site first: nothing on imagekbreducer.com ever contacts this API, and the browser tools work exactly as that policy’s section 1 describes whether this API exists or not.

The command-line tool runs on your own computer. Your image does not leave it.

This API is different by definition: when you send an image to api.imagekbreducer.com from your own server, that image leaves your device — that is what an API is. This API’s promise is therefore a different one from the website’s, and it’s the one stated above: uploads are processed in memory, never written to disk, and not retained. The compressed result is returned in the response and then discarded.

These are two separate promises about two separate products, and this site does not blur them. The full policy for imagekbreducer.com, including this same distinction, lives at imagekbreducer.com/privacy §1b.

What is actually kept

Three things, and nothing else:

• The hashed API key. Never the key itself — sha256(key), looked up on every authenticated request, written once by whoever issued the key.
• The name it was issued under, e.g. "rails-backend" — whatever label was given when the key was created.
• When it was issued — an ISO timestamp.

That’s the complete record. No request log ties a compress call back to its image, its filename, or its result, because nothing about a request’s content is written anywhere by this Worker’s own code. Cloudflare’s own platform-level request logs (method, path, status, timing, size — the same kind of metadata any web server logs) still exist at the infrastructure layer, same as they do for imagekbreducer.com; they contain no image bytes, because no image is ever written to anything this API’s code controls in the first place.

Contact

Questions about this policy, or about anything above that doesn’t match what you observe from this API: privacy@imagekbreducer.com — the same address that issues keys, see Authentication.