Cookie Policy

A “cookie” is a small text file that a website asks your browser to store on your device. When you return, the browser sends the cookie back, which lets the site recognise the device, keep you signed in, or remember a preference. Similar technologies — including localStorage, sessionStorage, and HTTP request headers such as authentication tokens — perform comparable functions and are treated the same way for the purposes of this policy.

We use these technologies for three reasons, in this order of priority: (a) to make the product work at all, in particular to keep you signed in and to defend the application against forgery and abuse; (b) to remember preferences you have set, such as theme; and (c) to understand, in aggregate, which parts of the product are used so that we can improve them. We do not use cookies to build advertising profiles, to retarget visitors across the open web, or to share information with data brokers.

Because KillBounce is a pay-as-you-go email verification tool with no advertising business model, our cookie footprint is deliberately small. You will not encounter a wall of third-party trackers here. Where consent is required — principally for visitors in the European Economic Area and the United Kingdom under the ePrivacy Directive and PECR — optional cookies are off by default until you affirmatively turn them on.

We group cookies into the categories below. Strictly necessary cookies are always on because the product literally cannot function without them. Everything else is either opt-in (in jurisdictions that require prior consent) or opt-out (elsewhere), and you can change your mind at any time from the cookie controls in the footer.

2.1 Strictly necessary

These cookies are required to deliver the service you have asked for. Without them you cannot sign in, you cannot submit a verification job, and we cannot protect the application against cross-site request forgery. Examples include the authentication session cookie, the CSRF token, and a short-lived load-balancing identifier. Under EU and UK law these cookies are exempt from the consent requirement because they are strictly necessary for a service explicitly requested by the user.

2.2 Functional

Functional cookies remember choices you have made so that the product behaves the way you left it. The clearest examples are your theme preference (light or dark), your saved dashboard layout, and a flag that records whether you have dismissed certain onboarding tips. These are convenience features — you can decline them and the product will still work, you will just be asked the same questions again on each session.

2.3 Analytics

We use PostHog as our product-analytics layer. Analytics events are pseudonymised at collection (we do not send your verification list contents, your password, or your API key), IP addresses are truncated, and aggregated counts are used to understand which pages get traffic and where users get stuck. In the EEA, the UK and Switzerland analytics are off by default and only enabled if you accept them in our consent banner. Elsewhere they are on by default and you can opt out at any time using the same banner or by sending a Global Privacy Control signal (see section 6).

2.4 Advertising

We do not set advertising or cross-site tracking cookies, we do not embed third-party retargeting pixels (no Meta Pixel, no LinkedIn Insight Tag, no Google Ads conversion tag, no TikTok pixel), and we do not sell or “share” personal information for cross-context behavioural advertising as those terms are defined under the CCPA / CPRA. If that ever changes we will update this policy and ask for fresh consent where required.

The table below lists the cookies and similar identifiers we currently use. We keep this list short on purpose — the trade-off is that the inventory has to be accurate, so if you find something in your browser that is not on this list and that you believe was set by us, please email privacy@getkillbounce.com and we will investigate.

We will refresh this table whenever the underlying inventory changes. The legal effect of a cookie depends on what it does, not on what we label it — so if a cookie we describe here as functional starts behaving like an analytics cookie, we will move it and ask for the relevant consent.

A small number of cookies are not set by us directly but by third parties whose code we load on our pages or whose iframes you interact with. These third parties are independent controllers for their own purposes and have their own privacy and cookie policies, which we link below. We engage each of them under written contracts and, where relevant, the EU Standard Contractual Clauses — see our Data Processing Addendum.

• PostHog — product analytics. Only loaded when analytics consent is granted (or by default outside the EEA / UK, subject to opt-out). We have configured PostHog with IP anonymisation and have disabled session recording on pages that show customer data.
• Dodo Payments — merchant of record for paid checkout. The checkout is rendered inside an iframe that Dodo controls; cookies set inside that frame (including Stripe-issued cookies, because Dodo uses Stripe-compatible infrastructure) are governed by Dodo’s policies. These cookies are required for fraud prevention and are categorised as strictly necessary while you are completing a purchase.
• Cloudflare — CDN, DDoS protection and bot management. The __cf_bm and cf_clearance cookies help Cloudflare distinguish human visitors from automated abuse. Without them we cannot keep the platform online during attack traffic, so they are treated as strictly necessary.
• Google / GitHub OAuth — if you choose to sign in with Google or GitHub, those providers may set cookies on their own domains during the sign-in flow. We do not control or read those cookies; they are governed by the provider’s policy.

We do not embed social media widgets, chat-bot SDKs that drop their own cookies, or third-party A/B-testing tools. If we add any in future, this section and the cookie banner will be updated before the cookies are set.

You have several independent layers of control and you can use whichever combination suits you.

Our cookie banner and preferences centre. Visitors located in the EEA, the UK and Switzerland see a consent banner on first visit; nothing optional is set until you choose. Visitors elsewhere can open the preferences centre at any time from the footer link and switch analytics off. Your choice is recorded in the kb_consent cookie so we do not ask again on the same device.

Browser settings. Every modern browser lets you block or delete cookies, either site-by-site or globally. Useful starting points are the help pages for Chrome, Firefox, Safari and Edge. Blocking strictly necessary cookies will break sign-in.

Device-level signals. We honour the Global Privacy Control (GPC) browser signal as an opt-out of analytics and of any future “sale” or “share” under the CCPA / CPRA. See section 6 for detail.

Account deletion. If you close your account, server-side identifiers linked to you are deleted in line with our Privacy Policy retention schedule. Cookies already stored in your browser remain until they expire or you clear them — we cannot reach into your browser to delete them retroactively.

The original “Do Not Track” (DNT) header has effectively been abandoned by browser vendors and standards bodies, and there is no agreed interpretation of what it legally requires. We therefore do not treat DNT alone as a binding opt-out, although we respect the spirit of it: even with DNT off, we do not run cross-site advertising or behavioural tracking.

The successor signal, Global Privacy Control (GPC), is supported and legally recognised in several US states. When we detect a GPC signal on a request we treat it as (a) an opt-out of analytics cookies for that browser, and (b) where the CCPA / CPRA or comparable US state law applies, a verifiable opt-out of any “sale” or “sharing” of personal information — even though we do not believe we engage in either today.

We say this plainly because it matters: if you send us a GPC signal and we are ever unable to honour it on a particular surface, that is a bug in our implementation, not a policy choice. Report it to privacy@getkillbounce.com and we will fix it.

We will update this Cookie Policy when our cookie inventory changes, when a new sub-processor is added that sets cookies, or when applicable law changes. Material updates — for example, adding a new third-party tracker or changing the lawful basis we rely on — will be announced through the consent banner and, where required, will reset any prior consent so that you can make a fresh choice. Non-material updates (clarifying language, fixing a typo, refreshing the expiry of an existing cookie) will be reflected by updating the “Last updated” date at the top of this page.

We keep older versions of our legal pages on file. If you need to see the version that was in effect on a particular date, email us and we will send it.

For questions about this Cookie Policy or to exercise the rights described in our Privacy Policy and GDPR notice, contact:

• Privacy and cookies: privacy@getkillbounce.com
• Data protection / DPO matters: dpo@getkillbounce.com
• Legal notices: legal@getkillbounce.com
• General support: support@getkillbounce.com

KillBounce is based in India. This policy is governed by the laws of India and any disputes arising in connection with it are subject to the exclusive jurisdiction of the courts at Bengaluru, except where mandatory consumer or data-protection law in your country of residence gives you the right to bring a claim locally.