Short version first: Zeed Search has no database table that records who searched what. Not a log that gets anonymized later, not a retention window that expires after 30 days — there is no column, no table, no place in the schema where “user X searched Y” could be written in the first place.
The original working title for this post was “a search engine that doesn’t store a single byte of your query.” That’s close, but not quite accurate, and being precise about the implementation matters more than a clean pitch. So this post draws the line exactly where it is: what’s genuinely absent, and what still remains, without softening either side.
Why build it this way
What you type into a search box is some of the most honest text a person types into a computer — health worries, money problems, a job search, a family situation. That’s exactly why most search engines treat history as an asset worth keeping: it improves ad targeting and search quality, and as a business model that’s entirely rational. This isn’t a criticism of that choice.
Zeed Search made a different one. Revenue comes from a Pro subscription — paying for the search experience itself — not ads, so there’s no upstream reason to accumulate search history as an asset in the first place. And data we don’t have can’t leak, can’t be sold, and can’t be looked at even by us. “We’ll protect it responsibly” is a weaker promise than “we don’t have it.” That’s the entire reasoning.
What is not stored
- A persistent query log. There is no table and no log file that a query gets written to. Application logs don’t emit query text either.
- Queries inside error reports. Before anything is sent to our error-tracking tool (Sentry), any line containing
q=is stripped programmatically. - IP addresses. Not stored. Free-tier rate limiting counts requests using a hash of (IP + date + salt) — an identifier that becomes unlinkable to anyone the moment the date rolls over.
- Behavioral logs — clicks on results, dwell time, and similar signals are not collected.
What still remains — the honest list
| Data | Where it lives | Duration / conditions |
|---|---|---|
| Recent search terms (up to 20) | Server memory only | Used for free-tier disambiguation and light personalization, scoped to an anonymous cookie, up to 30 days. Never written to disk; cleared on server restart. The Pro plan does not record this at all. |
| Search-result cache | Server memory only | Kept briefly to serve repeat queries faster; cleared after 5 minutes. |
| ”Shared” AI summaries | Database | Only the single item you explicitly share — the query and summary text. There is no column for who shared it. |
| Account info (Pro) | Database | Email address, Stripe customer ID, and plan tier only. Card details live with Stripe, not us. |
| Usage count | Database | Just a number — how many times the account was used today. What was searched is not part of it. |
What reaches external APIs
We don’t run our own search index or LLM from scratch, so query text does pass through external services partway through processing. Leaving this out would not be fair, so it’s stated plainly:
- Fetching results — queries go to Serper (a Google results API) or the Brave Search API.
- AI summaries and Deep Dive — queries and result excerpts go to Anthropic (Claude). On the free tier, up to 8 recent queries are also passed along as disambiguation context.
Both calls use only our own API keys — your account, IP address, and cookies are never attached. From the outside, the most anyone can see is “someone using Zeed Search searched this.” Who that someone is stays unknown to us and to them.
The stricter, legally worded version of this is in the privacy policy; the substance is identical to this post.
Try it without signing up
Zeed Search needs no install and no account — it runs straight from the browser. Try AI-assisted search without handing over your history.