Does SearXNG Autocomplete Send Partial Queries To Another Provider?

July 23, 2026

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:

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:

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:

  1. The user types a prefix.
  2. The browser asks the SearXNG instance for suggestions.
  3. The SearXNG instance asks the configured autocomplete backend.
  4. The backend returns possible completions.
  5. 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:

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:

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:

  1. Open the SearXNG preferences page and inspect the autocomplete choice.
  2. Ask the administrator whether the preference is locked or overridden.
  3. Check the instance's /config response; the Administration API exposes the configured autocomplete value.
  4. Inspect the effective settings.yml, not only a sample file.
  5. Use browser developer tools or a trusted network monitor with a harmless canary phrase to see when /autocompleter requests begin.
  6. 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 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

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:

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

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.