With the September 2016 introduction of the Brave Payments proof of concept, Brave began applying that mission to Web monetization, with features that combine zero knowledge and blockchain cryptography. Lessons learned from the Brave Payments proof of concept drove the evolution to the Basic Attention Token (BAT) and Brave Rewards, growing an ecosystem of private advertising and creator contributions to tens of millions of Brave Rewards users and over 2 million verified websites and content creators.

The economics of the Web are undergoing rapid change and innovation. AI adoption is changing the way users engage with content. Stablecoins and blockchain technology are upgrading the payments and transactional space, while merchants, restaurants, and the places we make everyday purchases adopt “cashless-only” payments. Without a digital alternative, the anonymity afforded by the wallet and cash in your back pocket may be lost in a cashless economy.

Creators continue to face challenges for how to fund their content, and those challenges have grown significantly with AI. With the growth of AI use and summarization, creators often have less visibility into where and how their content is being used, receive less attribution for that use, and generally are not compensated for it.

Users and creators should earn in this ecosystem, and not be left behind. Brave aims to rise to meet these new challenges, while growing BAT utility and the larger ecosystem. This means continuing the tradition of building solutions that meet users and creators where they are, and including them in the economics. This also means meeting users where they are transacting both within and beyond the browser. BAT Roadmap 4.0 therefore marks an important shift in the evolution of the Basic Attention Token, Brave Rewards, and Brave Creators within the transactional attention economy.

Initiatives

Roadmap 4.0 brings together the following mutually reinforcing initiatives:

• Internet-payments x402 and Machine Payments Protocol (MPP): Supporting autonomous agentic payments in the browser, for Brave’s premium offerings and for Creator content.
• A new, unified Brave Wallet: A new, in-browser Brave Wallet experience that brings traditional payment methods (including saved credit cards, self-custody crypto accounts, and Brave Rewards) into one intuitive interface.
• BravePay: A stablecoin protocol layer that enables users, creators, and merchants to transact, earn, and settle privately on-chain.
• Brave Rewards Card: A stablecoin-powered virtual and physical payment card with competitive purchase rewards.
• Creator Contribution Protocol: A system for compensating verified creators when their content is used in AI experiences.
• BravePay SDK and Rewards SDK: Open-source SDKs that allow developers to quickly integrate BravePay and Brave Rewards functionality.
  • For merchants, the SDKs will make it easy to support payment methods built on the BravePay protocol.
  • For app developers, the SDKs will enable user onboarding to BravePay-powered payments and provide access to the broader Brave Rewards ecosystem, including Brave Ads for additional monetization, and Brave Creators, connecting developers to millions of registered websites and content creators.

As we iterate and continue to pursue product-market fit, some of the roadmap items above may become less of a focus over time, while others may be prioritized. Useful roadmaps provide direction while remaining flexible enough to adapt to unforeseen challenges. We plan to publish regular updates on roadmap progress, along with publishing detailed posts and calls to action for the community for items in the sections below. 

Internet-payments x402 and Machine Payments Protocol (MPP) support in Brave

A key foundational step in supporting stablecoin payments for agentic commerce and autonomous systems, Brave will introduce support in the browser for x402 and Machine Payments Protocol (MPP) transactions. Brave’s implementation will use the HTTP 402 Payment Required status as a shared mechanism, providing equal first-class support for x402 and MPP options. For example, in the case of a Creator or API with protected content the browser will receive a 402 response code with a compatible x402 or MPP body, and provide payment for access to protected content. In addition to browser support, Brave will also be adding support for x402 and MPP transactions to the Brave Search API and other Brave offerings over time.

For a closer look, the open-source bx402 project with an example for the Brave Search API is available to view and reference from our brave-experiments GitHub repository.

A new, unified Brave Wallet

The browser-native, self-custodial Brave Wallet will undergo a complete redesign and evolve into the new unified Brave Wallet.

The new Brave Wallet will include:

• Traditional saved payment methods including debit cards, credit cards, and the Brave Rewards Card, all stored locally in the browser.
• Self-custody multi-chain crypto accounts with on- and off-ramp funding, the features users already know from the crypto Brave Wallet, and support for the upcoming BravePay protocol integration. 
• Brave Rewards integrated directly into the wallet, allowing users to opt in and earn rewards through use of the Brave Rewards Card, and benefit from transactions with participating partner brands and other Brave Wallet-related activities.

The team is looking forward to inviting participation in testing and feedback for the new Brave Wallet experience from the community and our userbase. We are aiming to post invitations with calls to action for users and the community to test and provide feedback for prototypes this fall.

The Brave Rewards Card

One of the most exciting initiatives in BAT Roadmap 4.0 is the Brave Rewards Card: a Brave-branded virtual and physical payment card designed for everyday purchases in eligible countries.

Powered by the BravePay protocol and GENIUS-compliant stablecoins, the Brave Rewards Card meets users and merchants where they are by leveraging traditional payment rails.

The Brave Rewards Card extends Brave Rewards beyond the browser. As users make purchases with the card, they will earn BAT rewards, while also unlocking exclusive Brave Rewards offers and benefits. The card will be available as both a virtual card in Brave Wallet (and other major digital wallets), as well as in physical form for in-store purchases.

To bring the Brave Rewards Card to users, Brave will partner with a compliant card issuer and support as many countries as possible at launch. Additional details regarding the card partner, geographic availability, purchase rewards, and the Brave Rewards Card waitlist will be shared in a future announcement. 

BravePay

Over the last several years, stablecoins have emerged as a powerful new payment rail, with tens of trillions of dollars in transaction volume. We aim to bring stablecoin-based peer-to-peer and e-commerce transactions into a protocol that’s easy to onboard and use, enabling more than 120 million Brave users to benefit from them.

To achieve this, Brave plans to introduce BravePay: a stablecoin protocol layer designed around self-custody, privacy, and ease of use.

What BravePay enables

• Self-custody by default: Users maintain control of their funds.
• Simple onboarding: New users can on-ramp from fiat directly into BravePay.
• Easy transactions: Payments can be sent and received using .brave addresses.
• Private transactions: Bringing privacy to your wallet so what you buy isn’t tracked by Big Tech or payment networks.
• Support for stablecoins: Experienced crypto users can transact using GENIUS-compliant stablecoins they already have in their wallets.
• Compatibility with x402 and MPP payment integration

Rollout strategy

Near term

• Integration with Brave Wallet
• Integration with the Brave Rewards Card

Longer term

• Merchant support for seamless e-commerce transactions.
• Introduction of an open-source SDK allowing developers to integrate BravePay into their applications.

BravePay will extend Brave’s user-first approach to privacy, transactions, and rewards beyond the browser, meeting users where they transact in the real world. 

Paving the way for the agentic economy

While our immediate focus remains on Brave users, we are closely watching the rapid development of machine-to-machine and human-to-machine payments in the emerging agentic economy. A growing number of protocols, including x402 and MPP, are competing for adoption.

BravePay lays the groundwork for payments between humans and machines alike. As this ecosystem evolves, Brave aims to enable browser-driven interactions with agents that unlock entirely new and exciting use cases with these agentic payment capabilities but with additional privacy-preserving options. This will start with BravePay compatibility with the Brave x402 and MPP implementation, and extend to other options over time.

BAT buybacks and Brave Rewards

In addition to the BAT purchases Brave already makes for user rewards through Brave Ads campaigns, the BAT Roadmap 4.0 introduces new transactional BAT utility and rewards for Brave Rewards users and verified Brave creators.

A percentage of Brave’s net revenue from Roadmap 4.0-related sources will fund BAT buybacks that support user rewards, creator contributions, and program growth through the BAT User Growth Pool (UGP) Reserve. For example, these revenue sources are expected to include:

• Brave Wallet revenue-generating features
• Swaps
• Cross-chain bridging
• NEAR Intents
• On- and off-ramps
• .brave domains sold through Brave Wallet
• Brave Rewards Card revenue, including revenue associated with the Brave Rewards Card as it becomes available in eligible markets.
• BravePay protocol revenue, a percentage of which will be used for BAT buybacks.

Additional details regarding relevant tokenomics in Brave Rewards will be shared in a separate blog post later in 2026, and will be included in relevant posts for other roadmap items as development progresses.

Opportunistic BAT buybacks

Brave also plans to make opportunistic BAT buybacks in addition to revenue-generated buybacks. These buybacks will support program growth, incentives, and expansion of the BAT UGP Reserve.

Buyback timing and amounts will vary based on market conditions and program needs. Brave will publicly disclose opportunistic buybacks through the Brave Transparency and BAT Ecosystem Growth pages.

Updates to Brave Rewards 

As Roadmap 4.0 expands BAT utility across Brave Wallet, BravePay, and the Brave Rewards Card, Brave Rewards will also evolve beyond its original browser-based rewards model. Users will continue to earn for their attention to eligible privacy-preserving Brave Ads units, while new rewards experiences will increasingly focus on offers, purchases, wallet activity, and loyalty.

Brave Ads

The Brave Ads Notification unit will begin a gradual sunset by the end of 2026 as Roadmap 4.0 utility features are activated. Over time, notifications will increasingly be used to inform Brave Rewards users about offers from participating brands and categories available through the Brave Rewards Offer Wall, rather than serving as ad units themselves.

Brave Rewards Offer Wall 

We will also introduce additional personalization features, including the ability for users to subscribe to favorite brands and categories for a more tailored Offer Wall experience.

Loyalty program

• Loyalty tiers that provide additional rewards based on Brave Wallet and Brave Rewards Card usage, duration of participation, and the amount of BAT held over time.
• BravePass, a crypto-abstracted Brave Rewards experience in which BAT earned through Brave Rewards is locked into a BravePass, giving the pass holder access to Brave Premium offerings and potentially other Brave benefits.

Together, these updates extend Brave Rewards from attention-based rewards into a broader rewards and loyalty system encompassing purchases, wallet activity, and more. As with Brave Premium and the existing Brave Rewards ecosystem, all of these new features can be implemented using privacy-preserving cryptographic protocols, allowing users to earn rewards without sacrificing their privacy. 

Creator Contribution Protocol

Today, AI models and tools use creator content during both training and inference without compensating the creators whose work makes those systems valuable. We believe that when AI systems generate value from creator content, a portion of that value should flow back to those creators in a verifiable way.

To make this possible, content creators, publishers, and AI products need to be connected through a shared, verifiable protocol. This is the Creator Contribution Protocol. With the protocol, we envision registered creators receiving micro-royalty payments for qualified content use when participating AI products access their content. 

BAT has already proven itself as the leading unit of account for attention on the Web, allowing millions of users to contribute to their favorite content creators. With millions of creators—including some of the world’s largest publishers—already registered with Brave Creators, Brave and BAT are in a unique position to lead by example on how content creators can earn with AI.

Later in 2026, we plan to publish a blog post specifically covering the Creator Contribution Protocol, and look forward to engaging with the community and Brave Creators to receive input and test as we go through the research and development process. 

Community 

Community participation will be a key part of BAT Roadmap 4.0. Over the past year, we’ve established a testing program and evolved the BAT Ambassadors program to support the road ahead. For example, BAT Ambassadors, alongside the broader BAT community, will help test, provide feedback on, and validate new features and experiences as they are introduced.

Building products that users adopt and enthusiastically recommend to their friends and family is central to the roadmap’s success. We’re excited to work closely with the community and our lead users to make this a reality. More details will be shared in future updates and calls to action.

Conclusion

Roadmap 4.0 brings BAT into a broader set of everyday interactions for users, merchants, and creators:

• The unified Brave Wallet combines traditional payment methods with next-generation transaction capabilities powered by BravePay.
• The Brave Rewards Card extends BAT utility to traditional payment rails, both inside and outside the browser.
• Revenue from Brave Wallet, the Brave Rewards Card, and BravePay will fund BAT buybacks that support purchase and transaction rewards for Brave Rewards users.
• The Creator Contribution Protocol modernizes the Brave Creators model, opening new verifiable ways for creators to earn as AI changes how content is created, curated, and consumed.

Together, these initiatives create a system in which browsing, transacting, and content creation can each contribute to sustained BAT demand and broader BAT utility across the evolving user-first Web.

Users and supporters of Brave can help advance this mission by adopting Brave Wallet and BravePay. Those who configure their AI agents to transact through BravePay will also position themselves at the forefront of the emerging agentic economy, and be rewarded for their participation.

Work with us

If your project aligns with this roadmap, we’d love to hear from you. Contact: bizdev@brave-cn.com to connect with us.

We look forward to building on this roadmap with our users and the broader Brave and BAT community, and we welcome your feedback and participation every step of the way. Follow the official Basic Attention Token (BAT) X for the latest announcements and product updates, and BAT Community X for community news, events, and discussions. We also invite you to join our weekly BAT Community Call every Tuesday at 2:00 PM Pacific on Brave Talk, with a live simulcast on X, featuring the latest updates and an open Q&A with the team.

This API is the backbone of place search in Brave Search, which handles over 2.2 billion queries a month and powers the Brave Search map. The improved version is available today for public access through the Brave Search API, on the Search plan, at a flat $5 per 1,000 requests.

Two things make the Place Search API worth your attention. First, the quality is comparable to Google Maps, as you will see on the experiment below (which tested a side-by-side comparison of Brave’s Place Search endpoint with 1,000 real queries). Second, Brave’s Place Search API is available at a fraction of the cost of the Google Maps API (which starts at $32 to $35 per 1,000 requests). This makes Brave 6 to 7 times more affordable for comparable place search.

This post details what the API returns, where it’s useful, how it measures up to Google Maps, and why building on Brave’s independent search stack matters.

What it does

One endpoint, accessing an index of about 200 million points of interest worldwide, as well as cities, countries, regions, and streets. This is the backbone of place search in Brave Search, which handles and powers the Brave Search map.

Send a query and a place to look:

curl "https://brave-cn.com/
  -H "X-Subscription-Token: <YOUR_API_KEY>"

No coordinates? Use a name instead, such as location=tokyo japan. Drop the query entirely and you get Explore mode: a snapshot of what’s around a point, ideal for map views. It even works without any location hints at all, doing a global search instead.

Every result comes back ready to render:

• Name, URL, coordinates, and full postal address
• Ratings, review counts, price range, categories, and cuisine
• Opening hours (including today), phone, email, and timezone
• Photos and distance from your search center

All these attributes are available on a flat rate of $5 per thousand requests. Compare that with Google, which charges you more for additional attributes.

Need deeper data? Every result carries an id. Pass it to /local/pois for more detail or /local/descriptions for AI-written summaries. The best part: those IDs also come from Web Search results, so one integration covers your local and Web surfaces at once.

Useful in multiple ways for apps and agents

You know your product better than we do. So we won’t tell you what to build. But the data is rich enough that one call covers jobs you’d otherwise wire up several APIs to handle:

• “Near me” discovery: restaurants, gyms, EV chargers, ATMs. Anchor to coordinates, set a radius, render a ranked list.
• Travel guides: explore mode plus the cities panel shows what’s worth seeing, then drills into hotels and attractions.
• Business directories: try “find a location near you” functionality without licensing a maps stack.
• Map dashboards: zoom_level hints and coordinates drop straight into your tiles.
• Geofenced nudges: try searches like “three highly-rated lunch spots within 500m.”
• AI agents: structured, current place data a model can reason over.

The point is the breadth. Where you take it is up to you.

Note the radius parameter will bias toward an area rather than hard-cutting at the edge. Under ~20 km it gives tight “near me” results. For a famous landmark, go wide or skip it. Match it to the job and results stay clean.

How it compares to Google Maps

Google Maps is the more mature product, and we won’t claim otherwise.

But the question that matters is whether Brave is good enough to build on, and what you gain by choosing it. To answer it, we ran 1,000 real, global, and multilingual place queries through both Brave and Google Maps. An LLM judge scored every pairing on recall, precision, ranking, and overall quality.

The result: a close second in overall quality: 6.4 vs 7.3 out of 10.

The two engines aren’t tied in character, though. They win in opposite places. That’s the useful part.

Where Brave wins:

• Coverage: Brave returns more of the places that actually exist (recall 7.2 vs 6.8). Google often returns fewer.
• Ambiguous names: Search "africa" near Johannesburg. Brave returns local businesses named “Africa” a kilometer away. Google returns the continent, 2,000 km out. Brave won this query type on recall 8.0 vs 6.1.
• Streets and addresses: For queries like "waka sakai line", Google’s place API often returns one far-away result or nothing. Brave returns the right nearby ones.

For the long tail of real local queries (e.g. names, addresses, streets, or anything fuzzy) — Brave is more likely to hand back something useful and close.

Where Brave trails:

• Category ranking: For “kebab near me,” Google floats closer results to the top more reliably.
• Fuzziness: Broader coverage drags in off-topic results sometimes (precision 6.2 vs 8.2).

So who should switch?

If you live in the long tail of names, addresses, and streets, or you value coverage, Brave is a strong fit today. If your traffic is mostly clean category search where precision is everything, Google’s Place Search API has an edge, but that edge is small. Try it on your queries.

Considering the price of the Brave Search API, it’s also worth exploring combining Brave and Google options to create an ensemble.

Caveats of the evaluation: The judge of the Brave-vs-Google Place Search API evaluation was an LLM (Opus4.8) which is extremely competent but not free of quirks. For instance, we have seen a bias towards length of the listings, where the judge rewards verbosity even if explicitly instructed not to. Another important caveat not captured by the judge is data-staleness. In that regard, Google has an edge that is hard to beat, as many business owners update changes on opening hours, phone numbers, etc. on the Google Business Profile before they do it on the Web itself. We get the data out of our Web crawler and Web Discovery Project (WDP) signals, which are by definition more limited than the direct input business owners give to Google.

The price difference, in full

Brave is a flat $5 per 1,000 requests, with every field included. And each plan includes $5 in free credit every month.

Google charges per SKU. The endpoints you’d use sit at the top of its price table.

At the entry tier, Brave is 6 to 7 times cheaper. And that’s before Google’s field-mask tiers push you higher. With Brave, ratings, hours, and photos all ride the same call.

(Google figures are from its official pricing table, 2026. Volume discounts exist for both.)

Built on an independent index

Most search APIs scrape their data from Google. That carries real risk for anyone shipping to customers.

Scraping violates Terms of Service. Google has litigated against providers over it. A scraped feed can be throttled or shut off, and it can’t offer true Zero Data Retention.

Brave is built differently. It runs one of only three independent, global-scale search indexes in the Western world, and the only one outside Big Tech. We own and operate the entire stack, Place Search included. That means:

• No scraper risk: Your product does not depend on a service that unofficially scrapes Google, which is subjected to unpredictable quality of service and risk of total discontinuation.
• Zero Data Retention: Queries aren’t stored, logged, or tied to identities.
• No conflict of interest: We don’t train our models on your queries.
• SOC 2 (Type II) attestation: Easier legal and security review.
• One platform, one set of IDs: Place Search, Web Search, POI details, and AI descriptions share IDs and the same $5/1k plan.

If you’re building with AI

Frontier models are becoming a commodity. The context you feed them is now what sets your application apart.

Our own research proves it. Ask Brave runs an open-weights model (Qwen) on Brave’s LLM Context API. It goes head-to-head with ChatGPT, Perplexity, and Google AI Mode (and wins) on the strength of better grounding data alone.

Place Search is the local half of that story. An agent that recommends a restaurant or answers “what’s open near me” needs structured, current place data. This endpoint returns exactly that, on the same Search plan as the LLM Context API. Web knowledge and world knowledge, one subscription.

To move faster, the API ships with Skills for Cursor, OpenCode, and Claude Code, plus an API Assistant in the portal that points you to the right endpoint and code.

Start now

curl "https://brave-cn.com/
  -H "X-Subscription-Token: <YOUR_API_KEY>"

Place Search is live on the Search plan. $5 per 1,000 requests. $5 in free credit every month. Enough to build something real today.

• Subscribe and get a key
• Read the API reference
• Load the Brave Search API Skills into your AI editor

Pricing sources:

• Google Maps Platform core services pricing list
• Places API Usage and Billing — Google for Developers

For example, a marketing manager might use containers to be logged into two different social media accounts at the same time. A developer might use containers to test an application with one tab logged in as an administrator and another as a regular user. An employee logged into their Google account might want to open YouTube in a separate container to ensure that their viewing history isn’t linked to their work account.

The original idea for Containers came about at a time when browsers gave different sites the ability to share storage with one another via third-party cookies and similar mechanisms. Since this privacy benefit is already built-in to Brave with storage partitioning (which isolates each site and its third-party requests so that trackers can’t follow you across the Web), containers are best understood as a convenience feature to present different identities to a site and as a basic building block for specific workflows.

To get started, simply go to Settings (brave://settings/braveContent) and click on Enable Containers. You can also right-click a tab, select “Open in container,” and choose the category.

Containers are now built into Brave 1.92 on all desktop platforms (Windows, macOS, and Linux), no extension/add-on needed. Note that this feature is being rolled out in phases over a few days, so if you don’t see it on your platform yet, please check back soon.

In short: zero-click search means no outbound click happened for that search interaction.

How zero-click search works

A no-click outcome can happen in several ways:

1. Answer-delivered outcomes: The results page surfaces a direct answer in a SERP feature (such as a featured snippet, knowledge panel, instant answer, or AI-generated summary), which often reduces the need to open another page.
2. Abandonment outcomes: The user does not find what they need and leaves without clicking any result.
3. Reformulation outcomes: The user changes the query and runs another search instead of clicking from the current results.

In all three cases, the defining signal is the same: the session ends without an outbound click from that results page.

Zero-click search vs. click-through and answer engines

• Click-through sends the user to a source page; a zero-click search does not.
• Answer engines are designed to produce direct answers; zero-click search is a broader behavioral outcome that can occur for multiple reasons.
• Traffic and measurement: Search value was often measured through clicks, but in a zero-click environment teams also track visibility, citations, and brand exposure.

Where zero-click search matters

• SEO and answer engine optimization (AEO): As more queries produce no-click outcomes, optimization shifts from only earning clicks to also earning presence and citation.
• Measuring success: Brands increasingly track impressions, citations, and assisted influence, since impact can happen without a site visit.
• Source attribution: Even when users do not click, answer features may still cite the underlying source.
• Building zero-click experiences: Developers use web grounding and a search API to generate in-context answers with citations.

Zero-click search reflects a shift from results pages as pure link directories toward results pages that can satisfy, redirect, or end a search interaction directly.

Related terms

SERP, SERP features, AI Overview, answer engine optimization (AEO), source attribution, web grounding, AI answer engine, conversational search, search API.

In short: a web search API is how software searches the Web—send a query, get back structured results to build on, with no browser or scraping required.

How a web search API works

The provider runs the search infrastructure so the developer just sends queries and receives data:

1. Maintain an index: The provider continuously crawls and indexes the Web, building the searchable corpus behind the API. (Note that scrapers generally do not maintain their own indexes of the Web.)
2. Authenticate: A developer calls an endpoint with an API key, which identifies the account and meters usage against a plan.
3. Query with parameters: The request carries the query plus options such as result count, freshness, country, and safe-search.
4. Rank and return: The service ranks matching pages and returns them as structured JSON, often grouped into web, news, image, and video results.
5. Consume programmatically: The application parses the structured results to power a search UI; to display or filter by type or freshness; or to feed those results as grounding context to an LLM.

The defining trait is that a web search API turns search into a building block: instead of a page for a person to read, it returns clean data for software to act on.

Web search API vs. consumer search engines and scraping

• Consumer search engines are websites people visit; a web search API delivers the same kind of capability to software as data.
• Programmable search engines are the underlying search systems; a web search API is the interface developers use to query it. The terms are sometimes used interchangeably in product marketing, but strictly speaking the API is how applications reach the engine.
• Scraping parses a rendered results page and is brittle and often disallowed; a true web search API (powered by its own index) provides sanctioned, structured access to results optimized for machine consumption.

Where a web search API is used

• Building search features: Powering site, app, or vertical search without running a crawler and index yourself.
• Web grounding and RAG: Supplying fresh, citable web content as the retrieval layer for web grounding and RAG, so a model can answer about the current world.
• AI agents and tools: Serving as the web-search tool an agent calls to look things up.
• Brave Search API: An independent web search API backed by Brave’s own index of over 40 billion pages, the Brave Search API has structured endpoints for web, news, images, videos, and local results, plus content pre-extracted for LLM grounding. Like any API, it is accessed by a plan with rate limits, and its coverage, freshness, and latency shape what you can build on it.

A web search API is what connects an application to the live web—the foundation under AI answer engines, grounded assistants, and any product that needs to search rather than be searched.

Related terms

Search API, programmable search engine, web grounding, retrieval-augmented generation (RAG), SERP, SERP features, AI web crawler, rate limiting, latency, AI answer engine.

In short: web grounding ties a model’s answers to fresh, real web sources fetched at query time, instead of relying on its training data alone.

How web grounding works

The model is given current web content to reason over before it answers:

1. Search: When a query needs current or factual information, the system searches the Web and gets back relevant, ranked results.
2. Fetch content: The system retrieves content from those pages in full text, extracted passages, snippets, or rich metadata and since the model can only reason over what it is handed. More complete content generally produces better grounded answers.
3. Inject as context: The retrieved content is placed into the model’s context window alongside the question.
4. Generate grounded answer: The model writes its answer from that supplied content, and typically attaches source attribution so each claim can be verified.

The defining requirement is freshness and fidelity: an answer is only as good as the content retrieved, so grounding depends on getting relevant, current content into the model’s context window.

Web grounding vs. RAG and ungrounded generation

• RAG is the general technique of retrieving documents to inform the generation of an answer; web grounding is RAG where the source is the live, public Web rather than a private corpus.
• Model training knowledge is a fixed snapshot bounded by its knowledge cutoff; web grounding can supply information about events and changes that occurred after that cutoff.
• Ungrounded generation answers from memory and may hallucinate; grounded generation draws on retrieved sources (which can also be cited). Ultimately, grounding reduces but does not eliminate unsupported claims.

Where web grounding matters

• Current questions: News, prices, weather, and anything else that changes after a model has been trained need live grounding to answer correctly.
• Trust and verification: Grounding lets a model cite real sources, which is how users and answer engines verify its claims.
• AI answer engines and agents: Grounding is what lets an agentic assistant answer about the live Web rather than its frozen knowledge.
• Search APIs as a common grounding layer: A search API is often the retrieval engine behind web grounding. It finds and returns web content for model grounding. Depending on the API, results may include URLs and snippets, extracted passages, or richer pre-formatted content. The Brave Search API includes an LLM Context endpoint that returns pre-extracted, relevance-ranked page content designed for grounding workflows.

Web grounding closes the gap between a model’s training data and the present moment. A search API is often the engine that does the closing.

Related terms

Retrieval-augmented generation (RAG), source attribution, hallucination, knowledge cutoff, AI answer engine, agentic search, semantic search, context window, search API.