Learn

Grok Web Search vs X Search: Which Tool Should You Use?

Web Search browses public web pages; X Search searches X posts, profiles, and threads. Compare filters, citations, media understanding, cost, and when to use either tool or both.

Separate adjacent ideas before you evaluate them. Use this page when similar names or layers sound interchangeable but lead to different decisions.

UpdatedJuly 11, 2026
Browse tool profiles

Editorial guide

Guide

Start with the core separation before you compare workflows, pricing, or plans.

Web Search and X Search are distinct server-side tools in the xAI API. The important difference is not general search versus advanced search. It is the source universe the agent can inspect and the controls you can apply. Web Search searches the internet and browses public web pages. X Search performs keyword, semantic, user, and thread retrieval across X posts, profiles, and conversations.

Start with the source that can actually answer the question. Use the Grok product overview for the broader product context, Grok pricing for maintained API and tool-call prices, and Grok subscription vs xAI API pricing when the unresolved question is whether to buy app access or fund an API workload.

The short answer

Decision factor

Web Search

X Search

Native source universe

Public web pages and internet search results

X posts, user profiles, and threads

Positive scope filter

Up to 5 allowed domains

Up to 20 allowed X handles

Negative scope filter

Up to 5 excluded domains

Up to 20 excluded X handles

Can positive and negative filters be combined?

No

No

Structured date range

Not listed in the current Web Search parameters

Inclusive from_date and to_date in ISO 8601 format

Image support

Page-image understanding and optional image search

Image understanding for images in posts

Video support

No Web Search video-understanding parameter

Video understanding for videos in X posts

Strongest fit

Official pages, documentation, pricing, policies, product facts, and broad public-web research

Fast-moving posts, account activity, community reaction, thread reconstruction, and early change signals

Use Web Search alone when the answer should come from canonical pages. Use X Search alone when the object of study is activity on X. Enable both when social posts can reveal a lead but a web page must confirm the fact. In a mixed workflow, label X evidence as social-source evidence until the relevant official documentation, pricing, legal, availability, or product page confirms it.

What Web Search controls

Web Search can search the internet, open pages, and extract current information from them. Its most important structured filters are allowed_domains and excluded_domains. Each accepts at most five domains, and the two cannot be used together in the same request. An allowlist is the safer choice for a canonical-source pass because it can restrict browsing to the vendor's documentation, pricing, status, support, or legal domains.

The published Web Search parameter table does not expose from_date or to_date. A date instruction in the prompt is therefore not the same control as the structured X Search date range. When a web claim is time-sensitive, inspect the page's publication date, last-updated date, effective date, region, and version rather than assuming the search result belongs to the intended period.

Web Search has two different image controls. enable_image_understanding lets the agent inspect images encountered while browsing pages. enable_image_search performs image search and can return Markdown image embeds; it is separate from understanding images found on ordinary pages. Web Search does not publish a video-understanding parameter. If Web Search and X Search are enabled together, turning on Web image understanding also enables image understanding for the X Search tool in that request.

What X Search controls

X Search is purpose-built for X data. The tool can perform keyword search, semantic search, user search, and thread fetch, which makes it better than a general web pass for finding an account, reconstructing a conversation, following reactions to an announcement, or examining how a claim spread across posts.

Its source filters are allowed_x_handles and excluded_x_handles. Each accepts at most twenty handles, and they cannot be combined in the same request. X Search also supports from_date and to_date; the documented range includes both boundary dates and uses ISO 8601 values such as YYYY-MM-DD.

A handle allowlist is not an automatic official-account or verification-status filter. xAI documents a list of literal handles, not an official or verified switch. If the research needs official X sources, identify the vendor's real account through its website or another source of record, then put those handles in allowed_x_handles. A renamed, compromised, impersonating, or incorrectly typed account can still corrupt the evidence boundary.

X Search can inspect images in posts when image understanding is enabled. It can also analyze videos found in X posts when video understanding is enabled; xAI documents that video capability as X Search only. These controls help when the evidence is inside a screenshot, chart, demo clip, or recorded announcement, but the resulting interpretation still needs the same source and claim review as text.

Citations are a trail, not proof

xAI exposes an all-citations list and optional inline citation behavior. The all-citations list contains URLs the agent encountered during successful search work. xAI explicitly notes that a URL can remain in that list even when it is not referenced in the final answer. That list is valuable for research traceability, but it does not prove that every source supports every sentence, or even that every listed source was used in the final synthesis.

Inline citations are stronger for auditing because they can be attached to specific spans and returned with positional metadata. Even then, xAI says enabling inline citations does not guarantee a citation on every answer. Defaults also differ by client: the Responses API enables inline citation behavior by default, while the xAI Python SDK requires an opt-in.

For every decisive claim, open the cited page or post and check the exact passage. Confirm that it supports the wording, scope, region, date, and product version. If several sources appear after a paragraph, do not assume each source supports every claim in that paragraph. Treat the model's synthesis as an interpretation layer over the sources, not a replacement for them.

Pricing follows tool activity, not user turns

Web Search and X Search currently carry the same published tool price: $5 per 1,000 successful server-side calls, equivalent to $0.005 per successful invocation. That tool charge sits alongside the selected model's input, reasoning, completion, cache, and applicable media-token charges. The maintained Grok pricing page is the safer place to check current rates before budgeting or publishing a cost example.

These search tools use the API billing route. xAI documents API credits and invoices separately from Grok consumer subscriptions, even though a consumer plan can include search inside the Grok app. Do not assume a subscription funds server-side API calls or that an app allowance maps to API entitlement. Use Grok subscription vs xAI API pricing to choose the buying route, then confirm account-specific entitlements in the xAI Console.

One end-user question does not equal one tool call. The agent decides whether to call a tool, which tool to call, and whether more calls are needed before it answers. A single API request can therefore make several Web Search calls, several X Search calls, both kinds, or none. xAI's successful server-side usage counts determine tool billing; attempted calls and successful billable calls can differ.

Image and X-video inspection add another boundary. xAI does not list a separate invocation fee for the view_image and view_x_video tools, but it bills the image or video tokens used for that analysis. Image Search is part of Web Search and is billed at the standard Web Search rate. For production cost tracking, inspect the response's usage and exact request cost instead of multiplying user queries by one assumed search call.

When to use one tool

Use Web Search alone

Choose Web Search alone when the source of record should be a public webpage: official pricing, API documentation, release notes, support policies, legal terms, service status, product availability, technical specifications, regulatory publications, or a broad source map beyond X. Use a domain allowlist when authority matters more than discovery breadth.

It also fits evergreen research where the final answer must survive beyond the social-news cycle. A vendor post may announce a change first, but the durable claim should point to the documentation or page that defines what customers can buy, access, rely on, or be bound by.

Use X Search alone

Choose X Search alone when X activity is itself the evidence: what a named account posted, how a thread developed, what users are saying, which posts contain a particular image or video, or how discussion changed within a defined date range. Handle filters and dates make this route especially useful for incident timelines, event reactions, creator discourse, and official-account monitoring.

Do not silently promote an X-only statement into a canonical product fact. Report it as a post, announcement, reaction, or lead unless the research question is explicitly about the post itself.

Use both

Use both when speed and authority live in different places. X Search can surface a new announcement, staff comment, outage report, customer reaction, screenshot, or thread before a search engine has indexed the definitive page. Web Search can then locate the official documentation, pricing table, status notice, legal text, or product page needed to confirm the material claim.

Enabling both tools gives the agent options; it does not force an orderly two-stage process. If the order matters, state it in the task: discover on X, extract candidate claims, verify each decisive claim on official web domains, then write the synthesis with the two evidence classes kept separate.

A two-source evidence workflow

  1. Classify the claim before searching. Mark it as a social signal, current product fact, price, plan entitlement, availability statement, legal or policy term, or interpretation. This classification determines what can count as final evidence.
  2. Use X Search for discovery when speed matters. Apply an official-handle allowlist only after verifying the handles, and add an inclusive date range when the event window is known. Capture the post URL, author, timestamp, thread context, and any media that changes the meaning.
  3. Promote only through Web Search. For pricing, entitlement, legal, availability, and product facts, search the relevant official domains and open the canonical page. If no confirming page exists, keep the statement labeled as an X announcement or unconfirmed lead.
  4. Audit citations claim by claim. Prefer inline citations for decisive statements, open the linked source, and treat the full citation list as a research log rather than a support matrix.
  5. Audit usage separately. Read successful server-side tool counts and the response cost. Do not estimate the bill from the number of user questions.

Claim type

Useful role for X Search

Evidence needed before promotion

Early feature or launch signal

Find the original post, account, thread, and reactions

Official product page, documentation, changelog, or release note

Pricing or plan entitlement

Detect that a change may have happened

Official pricing page and the plan or billing documentation that defines the entitlement

Legal, policy, or compliance statement

Locate an announcement or discussion

The applicable official terms, policy, trust, or legal page

Availability or incident status

Find live reports and affected-user context

Official status, support, availability, or regional documentation when the claim becomes definitive

Community sentiment

Measure posts and conversations on X

No web promotion is needed if the claim remains explicitly about sampled X discourse; document the sample and limits

This workflow deliberately allows X to be first without letting it become the source of record for every claim. It also prevents a domain allowlist from creating false confidence: an official domain can still contain a marketing page, stale document, regional variant, or page that does not support the exact conclusion.

Implementation guardrails

  • Enable only the tool or tools the task actually needs. Extra tools increase the search space and can increase cost.
  • Use either the positive or negative filter for a tool, never both in one request.
  • Verify account ownership before treating an allowed handle as official.
  • Preserve source type in notes and outputs: web page, X post, profile, thread, image, or video.
  • Require official web confirmation before promoting prices, plan entitlements, legal terms, availability, or product facts discovered on X.
  • Treat the all-citations array as an encounter log, not proof that every URL supports every claim.
  • Budget and monitor successful tool invocations, model tokens, and media tokens independently.

The durable decision rule is simple: Web Search is the default for canonical public facts, X Search is the specialist for X-native evidence, and both belong together when a fast-moving social lead must be converted into a verified web-backed claim.

FAQ

Common questions

What is the core difference between xAI Web Search and X Search?

Web Search searches the internet and browses public web pages. X Search is specialized for X posts, user profiles, and threads through keyword, semantic, user, and thread retrieval. Choose by the source universe the question actually requires.

Does allowed_x_handles automatically restrict X Search to official or verified accounts?

No. The parameter accepts literal X handles; xAI does not document an official-account or verification-status switch. Verify account ownership separately, then use up to 20 allowed handles if the workflow needs an official-source lane.

Can both tools enforce the same date range?

No structured date range is listed in the current Web Search parameters. X Search supports inclusive from_date and to_date values in ISO 8601 format. For web pages, verify publication, update, effective, region, and version dates on the source itself.

Does the returned citations list prove that every source supports the answer?

No. xAI says the all-citations list includes sources encountered during search, including URLs not referenced in the final answer. Inline citations provide a better claim-level trail, but every decisive source still needs to be opened and checked.

Does one API request create exactly one Web Search or X Search charge?

No. The agent may make multiple calls, use both tools, or use neither. Successful server-side invocation counts determine the search-tool portion of billing, while model tokens and applicable media tokens are charged separately.

When should a workflow enable Web Search and X Search together?

Use both when X can reveal a fast-moving lead, original post, thread, reaction, or media item, but the final claim needs confirmation on an official web page. Keep X evidence labeled as a lead until the canonical page supports the fact.

Next steps

Open both sides of the distinction

Open the most relevant product pages or follow-up guides for each side of the distinction after the split is clear.

View all tools