Last reviewed: October 16, 2026.
DeepSeek web search brings information from the web into the answering process, helping you investigate facts that may have changed or need a source. The final answer still needs checking: DeepSeek’s Terms of Use say Search can improve accuracy to some extent, while errors can remain.
There is also a privacy consideration before you search. DeepSeek’s Privacy Policy says it uses third-party search APIs and shares input keywords to provide that service. Choose what to submit with that additional sharing in mind.
This guide starts with Search in DeepSeek Chat, then separates Harness and developer integrations. API tool support and request fees should not be treated as consumer-app settings or subscription requirements.
When to use DeepSeek Search
Use Search when the answer depends on information outside the conversation that needs to be current or independently verifiable. Model knowledge is often sufficient for a stable explanation, a writing task, or reasoning over material you provide. If your research depends on X posts, compare the search workflows in our DeepSeek vs Grok guide.
| What you need | Best starting point | What to check |
|---|---|---|
| Current hours, availability, news, or product documentation | Search | The original source, relevant date, and any exceptions |
| A factual answer with traceable evidence | Search | Whether the linked passage supports the exact claim |
| A stable concept explained, an outline, or a rewrite | Model knowledge | Clarity and correctness; request sources if they matter |
| Analysis of text or a document you supplied | The supplied material | Whether the answer stays within that material or needs outside facts |
Model knowledge comes from training; retrieval supplies additional material for a particular task. The model generates an answer from the available context, so a linked page does not automatically support every sentence around it. Check both the retrieved material and the interpretation built from it.
Reasoning or Deep Thinking concerns how the model works through a problem. It does not, by itself, prove that a web search occurred. Searching uploaded files or chat history covers a different collection of material. Opening one URL is also a different task from searching for relevant pages. A plausible reference generated in prose establishes none of these actions.
Start a search, then inspect the evidence
Open official DeepSeek Chat or the mobile app linked under DeepSeek app on DeepSeek’s official download page. If your interface offers a Search control, enable it, enter your question, and send it. When the response arrives, open any source links or citation controls it provides. DeepSeek’s terms document Search without establishing one universal button location or source-panel layout across web and mobile.
Ask a specific question that names the entity and the facts you need. For example:
Search the official Smithsonian National Museum of Natural History website for its current visiting hours and closure exceptions. Link to the page supporting each detail. If a source has no publication or update date, say so.
That request makes the intended research clear. It does not force a completed search or enforce an “official sources only” restriction. Verify the destinations yourself.
What actually indicates that retrieval happened?
Separate four things when you review the response:
- Your request or selected control. This expresses the task you want performed. It does not establish that retrieval finished.
- Visible search activity or tool records. If your interface exposes these, inspect whether they report a completed operation, an error, or only an attempt. An assistant saying “I searched” is a claim about its behavior, not a tool record.
- Returned source information. Open any source links or citation controls the interface provides. A reachable page establishes that the destination exists; a recent-looking date or a URL in prose does not establish that the model read it.
- Support for the answer. Compare the statement with the page. Retrieval can succeed while the answer misreads, combines, or overextends the evidence.
If the interface does not reveal enough information, treat retrieval as unconfirmed from what you can see. Missing one familiar icon is not proof that no search occurred. You can still assess the answer’s claims by opening primary sources yourself.
Check whether a citation supports the claim
Treat each citation as a route to evidence. Before relying on a consequential statement, check the part of the answer that matters to your decision.
- Open the destination and identify the publisher. Check the actual domain, page title, and responsible organization. For a company’s feature or policy, start with that company’s documentation. For an event, look for the organizer or original record.
- Find the supporting passage. Search the page for the relevant phrase, number, or claim. Read the surrounding sentences and footnotes. A citation may support one clause while leaving the rest unsupported; a report that someone made an allegation does not establish that the allegation is true.
- Match the scope. Confirm the product, version, country, plan, population, or location. A feature documented for one API integration does not establish availability in the consumer app. For US readers, check that an international page’s conditions apply in the United States.
- Check the dates that affect the answer. Separate the publication or update date from the event date or policy effective date. A retrieval or crawl timestamp records a different event. A footer year, search-result date, or refreshed badge does not prove the underlying fact was reviewed.
- Trace and corroborate important facts. Follow secondary reporting back to the original document when possible. Seek independent evidence when the stakes or uncertainty justify it. Several sites repeating one report do not provide several independent confirmations.
Missing dates should stay missing. For a changing fact, look for a current official page, applicable release note, or other evidence that resolves the timing. For a stable fact, an older primary source can be more useful than a recent summary. Recency helps only when it is relevant to the claim.
A real page can still support an overbroad answer
Consider this hypothetical claim: “All Smithsonian museums are open until 5:30 p.m. every day.” The National Museum of Natural History’s visitor page lists that museum’s hours as 10 a.m.–5:30 p.m., with a December 25 closure. It does not establish hours for every Smithsonian museum, and the exception contradicts “every day.”
A supported version would be: “The Smithsonian National Museum of Natural History lists regular hours of 10 a.m. to 5:30 p.m. and is closed on December 25.” The correction names the specific museum and preserves the exception.
If a page cannot be opened, mark the evidence as unverified rather than automatically calling it fake. Request an accessible primary source or check the original organization directly. If sources disagree, compare their dates and scope instead of choosing the answer with more citations.
What Search means for your privacy
The DeepSeek Privacy Policy, updated February 10, 2026, states:
We integrate third-party APIs to provide search services, and we will share your input keywords to provide these services.
The stated sharing is part of providing search. The clause does not name the current search provider, define the exact keyword payload, or give a search-provider retention period. It does not establish that only keywords are shared, that queries are anonymized, or that your entire chat history is transferred.
For a public-information question, include the details needed to find the answer and leave out unrelated identifying or confidential context. Search terms themselves can reveal sensitive information even without an attachment.
Here is a fictional query rewrite: replace “Find Firefox’s current tracking-protection documentation for our confidential Project Cedar rollout for Client Northstar” with “Find Mozilla’s current documentation for Firefox’s tracking-protection settings.” The public question remains useful without the client and project names. Distinctive details left in a query can still identify a person or organization.
Search, training controls, and deletion do different jobs
- Turning Search off does not make hosted Chat offline. The general Chat privacy policy still describes processing of submitted inputs. Use Search settings to decide whether the task needs retrieval, not as a promise of private local processing.
- A training opt-out is a separate control. Section 4.3 of DeepSeek’s Terms of Use identifies “Improve the model for everyone” as the setting for the described model-improvement use. That provision does not promise to stop search-provider sharing.
- Deleting a chat or account is not a blanket downstream erasure guarantee. The privacy policy’s retention provisions and account-deletion terms describe retention conditions. Neither gives a universal promise that every search provider immediately deletes every related record.
Before searching with workplace information, reduce the query to the public facts you need and follow your organization’s rules for the service. When the confidential context is essential, an approved internal research process may be the appropriate route.
For the broader collection, retention, and opt-out rules, read our DeepSeek privacy policy explanation.
How web search in DeepSeek Harness differs
DeepSeek Harness is a separate agent application, so its tools and settings need their own assessment. A familiar model name does not establish that Harness uses the same search route or privacy arrangements as Chat.
Harness’s current web-access documentation describes two distinct tools: web_search finds pages through a configured search provider; web_fetch retrieves content from a particular URL. The documentation lists DeepSeek, Exa, and Perplexity search providers. Check the configuration that applies to your installation rather than assuming one provider is universal. For a product-level comparison of research and citations, see DeepSeek vs Perplexity.
Source dates or excerpts may be missing, and fetched content may be truncated or contain an error response. Inspect the underlying page before relying on a claim; do not fill in missing evidence.
The DeepSeek search-adapter README describes a particular Messages-based implementation. Treat that as documentation for the adapter, not a complete inventory of DeepSeek’s services. Its statement about the absence of a dedicated search endpoint should not override the standalone Search and Fetch services listed in the current platform pricing. Check the installed adapter rather than assuming it automatically uses a different retrieval service.
Check the policy for your Harness configuration
The separate Harness Privacy Policy, updated September 20, 2026, distinguishes official-model and custom-provider scenarios. For a custom model service, it describes inputs going directly to that provider and outputs returning directly, without Harness server-side processing or storage of those inputs and outputs in that scenario.
That statement has a specific scope. The policy separately discusses session logs and third-party tools or services. It does not establish that every Harness task stays local or that web tools send no data elsewhere. Check both the selected model service and the search service, including their applicable policies.
A third-party website, extension, or client using DeepSeek models can have another configuration and privacy policy. Establish who operates it before applying the official Chat instructions or policies to it.
DeepSeek web search through the API
For developers, distinguish a tool executed inside a model response from a separate retrieval service. The Search control in Chat and the name of a Harness tool do not establish an API compatibility guarantee.
Responses API: built-in search depends on the model
The official Responses API documentation specifies the following behavior for the built-in web_search tool:
| Model | Built-in search behavior |
|---|---|
deepseek-v4-pro | Supported. DeepSeek runs the search on the server, adds the results to the context, and continues the response. |
deepseek-flash | The built-in web_search tool is ignored. |
This restriction concerns that built-in Responses tool, not every way an application can supply retrieved material to Flash. To verify a Pro search, inspect returned web_search_call records or their documented streaming events rather than relying on “I searched” in generated prose.
Standalone Search and Fetch are not model names
Searching for relevant pages and fetching the content of a selected URL are different operations. DeepSeek’s Models & Pricing page lists Search and Fetch as standalone APIs, billed by successful requests rather than model tokens.
Use the provider’s Search & Fetch guide for request formats and the detailed definition of a billable request. Keep retrieved material separate from the model’s synthesized answer: locating or fetching a page does not establish that the answer interprets it correctly.
Codex and Claude Code have different integration rules
In DeepSeek’s official Codex integration, the setup script disables built-in search by default. With an already-configured DeepSeek provider, enable it by selecting deepseek-v4-pro and setting web_search = "live" in the user-level ~/.codex/config.toml, then restart Codex. Preserve the rest of the provider configuration. The Flash example remains disabled; a disabled default is not a permanent lack of support.
The Claude Code integration documentation separately describes native search through DeepSeek’s Anthropic-compatible route and additional model requests to summarize search results. Do not apply the Pro-only Responses search restriction to a different integration without checking its own documentation.
Search request fees and model-token costs are separate
The published U.S.-dollar request rates are:
| Standalone API | Billing unit | Published price |
|---|---|---|
| Search | 1,000 successful requests | $0.75 |
| Fetch | 1,000 successful requests | $0.75 |
The pricing page also describes a two-week launch waiver of Search request fees for built-in search in Codex and Claude Code, with the billing start date to be announced separately. Check the applicable announcement and account billing; do not invent a cutoff date or extend that waiver to every client.
A Search-fee waiver is not a promise of free model inference. The Claude Code documentation explicitly warns of model-token costs for summarizing retrieved content. For account balances and token-cost tracking, see our DeepSeek API billing guide; track retrieval fees as a separate cost category.
What to do when Search or its sources are unavailable
- If Search reports an error, check the official DeepSeek status page, which lists Search Service separately. A status report can help identify a service issue; it cannot diagnose every account or device problem.
- If a Search control is missing, check the current documentation for that interface and any access requirements it actually states. Do not assume that changing a reasoning mode enables web retrieval.
- If a linked page is inaccessible, request another original source or visit the responsible organization’s website directly. An inaccessible source is a different problem from a failed search.
- If the search completed but the evidence is weak, narrow the question to a specific entity, date, or version. Ask which passage supports the disputed detail and leave the claim unresolved if none does.
- For a Responses integration, check the selected model before diagnosing an ignored
web_searchtool as an outage. The Pro and Flash cases in the table above are different. - For Codex, check both the model and the
web_searchsetting. The setup script’s disabled default is a configuration choice, not proof that search is unavailable with Pro.
For a rewrite or stable explanation, continuing without Search may be sufficient. For a current factual decision, use an accessible primary source or wait until retrieval can be checked. Turning Search off does not preserve live verification.
