Does SearXNG Autocomplete Send Partial Queries To Another Provider?
Yes, when an external autocomplete backend is enabled, SearXNG can send the query prefix to that suggestion provider before the user submits the full search.
Yes. When SearXNG is configured to use an external autocomplete backend, it can send the text already typed in the search box to that suggestion provider before the full search is submitted. The provider normally sees a request from the SearXNG instance or its proxy, not directly from the user's browser, but the partial query itself can still leave the self-hosted system.
Last updated: July 23, 2026
Who This Is For
This guide is for people who:
- self-host SearXNG for private web search
- connect SearXNG to an AI chat or research workflow
- use search suggestions but assume no query leaves until Enter is pressed
- need to decide whether autocomplete is worth its extra data path
- administer a public, private, home, or company SearXNG instance
The important distinction is between where the request originates and what the request contains. SearXNG can shield the browser's direct identity from an autocomplete service while still forwarding the current query prefix through the instance.
The Short Answer: Autocomplete Creates A Pre-Submit Request
SearXNG's current search settings documentation lists external autocomplete backends including Bing, Brave, DuckDuckGo, Google, Qwant, Startpage, Swisscows, Wikipedia, and others. The same documentation says leaving the autocomplete setting blank turns the feature off.
The current SearXNG autocomplete source shows what happens after a backend is selected. Backend functions put the current query into an outbound request parameter such as q, query, search, phrase, part, or word, depending on the provider. For example:
- Brave receives the query in a
qparameter. - DuckDuckGo receives it in a
qparameter. - Google receives it in a
qparameter. - Wikipedia receives it in a
searchparameter. - Yandex receives it in a
partparameter.
SearXNG's web application source routes the browser's autocomplete request through /autocompleter, extracts the query prefix, reads the selected autocomplete backend, and passes the prefix to that backend.
That is a separate path from the eventual search:
- The user types a prefix.
- The browser asks the SearXNG instance for suggestions.
- The SearXNG instance asks the configured autocomplete backend.
- The backend returns possible completions.
- The user may continue typing, choose a suggestion, submit a different query, or never submit a search.
The autocomplete provider can therefore receive text that never becomes the final search.
A Concrete Example
Suppose someone intends to search for:
Acme Northstar acquisition risk analysis
With autocomplete enabled, the suggestion path may be triggered after an initial threshold and again as the text changes. Depending on the client behavior, configuration, and typing speed, an external backend could receive prefixes such as:
AcmeAcme NorthstarAcme Northstar acquisitionAcme Northstar acquisition risk
The final search might instead become:
public acquisition risk checklist
Submitting the safer final query does not retroactively remove prefixes that were already sent for suggestions. This is why autocomplete should be treated as an outbound data path of its own, not merely as decoration inside the search box.
What Each Party Can See
| Party | What it can receive | What it does not automatically learn |
|---|---|---|
| Browser | The text the user types and the suggestions returned | How every upstream provider stores or uses the prefix |
| SearXNG instance | The autocomplete request, query prefix, language preference, timing, and browser connection metadata | The user's real-world identity unless other account, network, or log data links it |
| Autocomplete backend | The forwarded prefix, locale-related parameters, timing, and the instance or proxy network address | Usually the browser's direct cookies and direct IP when the request is brokered by SearXNG |
| Reverse proxy or host | Connection and request data according to its configuration and logs | A guarantee that the application itself stores a lasting query record |
| Full-search engines | The query submitted for the actual search | Prefixes sent only to a different autocomplete provider |
This table describes the likely data path, not a universal retention policy. Whether a SearXNG operator, hosting provider, proxy, or suggestion service retains anything depends on its configuration and policy.
Does Self-Hosting Prevent The Autocomplete Provider From Seeing The Prefix?
No. Self-hosting changes who operates the broker; it does not turn an external suggestion backend into a local service.
SearXNG's private-instance documentation explains that upstream services normally see the instance's IP address rather than the individual browser's IP. It also notes that operators of private instances control their own source code, logging settings, and private data.
Those are meaningful privacy benefits. They can remove an unknown public-instance administrator from the path and reduce direct linkability to the user's browser. But if Google, Bing, DuckDuckGo, or another external autocomplete backend is selected, that service still needs the prefix to generate relevant suggestions.
Think of self-hosting as control over the relay, not as proof that the relay never contacts another service.
Does A Proxy Or Tor Keep The Prefix Private?
A proxy or Tor can change the network address visible to the suggestion provider. It does not remove the words in the request.
SearXNG's outgoing-request settings support proxies, source-IP choices, and Tor routing for outbound communication with search engines. Those controls can make the provider see a proxy or Tor exit rather than the SearXNG server's normal public IP.
The tradeoff is a different trust boundary:
- direct egress exposes the instance's public IP to the autocomplete backend
- a proxy exposes the request path to the proxy operator and the proxy IP to the backend
- Tor exposes the Tor exit to the backend and can reduce reliability
In all three cases, the autocomplete backend can still receive the query prefix unless autocomplete is disabled or replaced with a truly local suggestion source.
The Current Default Matters, But Your Deployment Matters More
The current SearXNG settings.yml leaves autocomplete blank by default, which turns it off. It also defines an autocomplete_min value of 4, meaning the standard client is configured not to start autocomplete until at least four characters have been typed.
Do not assume those defaults describe a deployed instance.
An administrator can select a backend, change settings, lock preferences, or run a different release. A user may also be able to choose a different autocomplete backend in Preferences when the administrator has not locked that setting. A browser's address-bar integration can create a related suggestion path with behavior that differs from the normal webpage search form.
Verify the actual instance:
- Open the SearXNG preferences page and inspect the autocomplete choice.
- Ask the administrator whether the preference is locked or overridden.
- Check the instance's
/configresponse; the Administration API exposes the configured autocomplete value. - Inspect the effective
settings.yml, not only a sample file. - Use browser developer tools or a trusted network monitor with a harmless canary phrase to see when
/autocompleterrequests begin. - Inspect the SearXNG server's outbound destinations to identify the actual suggestion provider.
What This Does Not Mean
External autocomplete does not automatically mean:
- the suggestion provider sees the user's direct browser IP
- SearXNG forwards the browser's search-engine cookies
- the provider receives the complete chat conversation
- the prefix is permanently stored
- the full search uses the same provider as autocomplete
- every character creates a separate successful outbound request
- disabling autocomplete makes the entire search workflow local
- self-hosted SearXNG offers no privacy benefit
- a proxy removes sensitive words from the request
- a private AI tool never uses necessary provider processing
The accurate claim is narrower: an enabled external autocomplete backend adds a pre-submit outbound request that can contain the query prefix.
Autocomplete vs Full Search
| Question | Autocomplete | Full search |
|---|---|---|
| When can it happen? | While the user is still typing | After the user submits the query or an app triggers search |
| What text is sent? | The current prefix | The submitted or model-generated search query |
| How many providers receive it? | Usually the selected suggestion backend | One or more enabled search engines |
| Can the text differ from the final query? | Yes | It is the final query for that search action |
| Can it be disabled separately? | Yes, by leaving autocomplete blank | Search requires at least one data source |
| Does self-hosting keep it local? | Only if no external backend is called | Not when external search engines are queried |
This separation is especially important in AI workflows. An AI application may generate and submit search queries without using the human-facing SearXNG search box at all. In that case, SearXNG's webpage autocomplete may be irrelevant, while the model, search tool, page fetcher, and full-search engines remain part of the data path.
Nine Checks Before Enabling SearXNG Autocomplete
- [ ] Which autocomplete backend is selected?
- [ ] Is the backend external, self-hosted, or truly local?
- [ ] What is the effective
autocomplete_minthreshold? - [ ] Can individual users change the autocomplete provider?
- [ ] Does the browser address bar request suggestions separately?
- [ ] Does the SearXNG instance or reverse proxy log
/autocompleterrequests? - [ ] Is outbound autocomplete traffic direct, proxied, or routed through Tor?
- [ ] Are users likely to type client names, health details, credentials, internal URLs, or unreleased project terms?
- [ ] Have you verified behavior with a harmless canary query rather than trusting the configuration label?
If the answer to any of these is unknown, treat autocomplete as an external processing path.
A Safer Configuration Strategy
1. Disable External Autocomplete For Sensitive Work
The strongest way to stop SearXNG from forwarding prefixes to an external suggestion backend is to leave autocomplete blank. The official search settings documentation explicitly identifies the blank value as the way to turn autocomplete off.
2. Raise The Minimum Only As A Partial Measure
Increasing the minimum character threshold can prevent very short prefixes from triggering suggestions. It does not stop longer prefixes from being sent once the threshold is reached. A four-character minimum, for example, does not protect a four-letter surname, acronym, product code, or medical term.
3. Minimize Before Typing
Rewrite the intended search before entering it into an autocomplete-enabled box:
- replace a client's name with an industry
- replace a product codename with a generic product category
- remove credentials, tokens, email addresses, and internal URLs
- search the public concept before adding a distinctive detail
- avoid pasting a private sentence and editing it down in the search box
4. Audit Logs Separately
Disabling an external suggestion backend does not prove that the SearXNG instance, browser, reverse proxy, container platform, or host keeps no logs. Logging is a separate control. SearXNG's private-instance guidance specifically tells operators to consider their own logging settings.
5. Verify The Complete Search Chain
Autocomplete is only one hop. A privacy review should also cover the model that creates the query, the engines that receive the full search, the proxy or Tor route, DNS, result-page fetching, the model that reads retrieved content, and operational logs.
For that broader audit, read Does Self-Hosting SearXNG Keep Every AI Search Query Private?. For query minimization, read Can AI Web Search Expose Sensitive Terms Even When The Full Prompt Is Not Shared?.
Where OpenVeil Fits
OpenVeil is a paid, privacy-focused AI chat workspace with browser-local chat history and no server-side chat-history record for normal private chat sessions. It offers web search, uploads, voice, and image tools where enabled.
This article does not claim that OpenVeil uses SearXNG or any particular autocomplete provider. OpenVeil's documented privacy boundary is narrower: active requests may still be processed by OpenVeil and necessary AI, search, hosting, routing, security, upload-processing, and infrastructure providers.
The practical tradeoff is hosted convenience. OpenVeil users do not need to operate and update a SearXNG instance, choose autocomplete and search backends, configure proxies, or maintain an AI search stack. That convenience does not make web search fully offline or eliminate necessary provider processing.
Before searching for sensitive material, review OpenVeil's privacy policy and minimize the terms that are not needed to retrieve public information. You can also read What To Check Before Trusting Any AI Privacy Claim for a broader buyer checklist.
Frequently Asked Questions
Does SearXNG send every keystroke to Google?
Not necessarily. It depends on whether autocomplete is enabled, which backend is selected, the minimum-character threshold, client timing, and whether requests complete. If Google is the selected external backend, the current prefix can be sent to Google's suggestion endpoint after the threshold is met.
Is autocomplete off by default in SearXNG?
The current default settings.yml leaves the autocomplete value blank, which turns it off. Administrators and, when allowed, users can change the active setting. Verify the deployed instance instead of assuming it still uses the default.
Does the autocomplete provider see my real IP address?
The provider normally sees the SearXNG instance's outbound IP or a configured proxy or Tor exit, not the browser's direct connection. A home-hosted instance's public IP can still be associated with the household or server operator.
Can I keep suggestions without using Google or Bing?
SearXNG supports multiple autocomplete backends, including Wikipedia and other services. Choosing a different external backend changes the recipient; it does not make the request local. A truly local suggestion system would need a local data source and implementation.
Does setting autocomplete_min to a higher number solve the privacy issue?
It reduces which short prefixes can trigger requests. It does not prevent the longer prefix from being sent after the threshold. Disabling external autocomplete is the clearer control when pre-submit sharing is unacceptable.
Does disabling autocomplete keep all SearXNG searches private?
No. It removes the suggestion request, but submitted searches can still be sent to configured external engines. Page fetching, proxies, DNS, hosting, logs, and AI model processing can create other data paths.
Does SearXNG store autocomplete queries?
SearXNG's project documentation says it is designed not to store information about users, but a deployment can include reverse-proxy, web-server, platform, or custom logging. The autocomplete provider also has its own practices. Audit the actual instance and provider rather than assuming a universal retention result.
Does an AI app connected to SearXNG use this browser autocomplete route?
Often it does not. An AI tool may call SearXNG's search API directly with a model-generated query. That skips the webpage's typing suggestions but still sends the submitted query to SearXNG and its selected search engines.
Bottom Line
An enabled external SearXNG autocomplete backend can receive partial search text before the user submits a full query. SearXNG brokers that request, so the provider generally sees the instance or proxy network address rather than the browser's direct identity, but the typed prefix can still leave the self-hosted environment.
If pre-submit sharing is unacceptable, disable autocomplete by leaving the setting blank. Raising the minimum character count only delays the request. Then audit full-search engines, page fetching, model processing, proxies, DNS, hosting, and logs because turning off suggestions does not make internet search fully local.
Explore OpenVeil or read the privacy policy before using web search with sensitive material.
Sources
- SearXNG Documentation: Search settings and autocomplete backends
- SearXNG Documentation: Autocomplete source module
- SearXNG source: Web application autocomplete route
- SearXNG source: Current default settings
- SearXNG Documentation: Why use a private instance?
- SearXNG Documentation: Outgoing request settings
- SearXNG Documentation: Administration API
- NIST Privacy Framework