Twitter Advanced Search Operators: Full Syntax Reference

Twitter's search operators are the difference between pulling a keyword feed and pulling exactly the tweets you meant. Twitter's own documentation of them is incomplete, scattered, and often outdated, so this guide is a working reference to every operator that actually functions on Twitter/X in 2026: what each one matches, how they combine, which ones are silently broken, and tested query examples for each. Operator behavior here was checked against real queries and cross-referenced with the community-maintained igorbrigadir/twitter-advanced-search repo.

These operators work in two places: Twitter's own search box, and any API that passes the web operator set through. If you are choosing a search API rather than learning the syntax, the Twitter search API page covers endpoints, pagination, latency, and pricing; this guide stays on the query language itself.

The Two Operator Sets (Read This First)

Twitter has two entirely separate operator sets, and confusing them is the single most common reason an advanced filter silently returns nothing useful.

The web search operator set, used on twitter.com/search, is the one documented in this guide: engagement filters, geo filters, app-source filters, and everything below. The official X API operator set is a different, smaller vocabulary. Some capabilities exist on both sides under different names (engagement thresholds are min_faves:/min_retweets: on web but min_likes:/min_reposts: on the API), and some operators, like within_time: and filter:blue_verified, have no API equivalent at all.

So a query copied from a web-search tutorial can fail against the official API: X documents that min_faves: and min_retweets: are rejected with a 400 error there. Check which vocabulary your access expects before debugging your syntax, and see the search API comparison for which providers accept the full web set.

---

Concretely:

1. Web search operators, everything in this guide. Used on twitter.com/search, TweetDeck, and passthrough APIs.
2. Official X API operators, a different vocabulary. Engagement filters exist but are renamed (min_likes:, min_reposts:), and operators like within_time: and filter:blue_verified have no equivalent.

If you are querying through the official X API, translate the engagement names and expect the rest of the web-only operators to be rejected or unavailable.

---

1. Keyword and Boolean Logic

Keyword and Boolean operators are the building blocks of every Twitter search query. Implicit AND requires both terms in the tweet, OR (uppercase) matches either, quoted phrases require exact order, the minus sign excludes terms, and url: matches a tokenized domain anywhere in the tweet text.

These are the basic building blocks of every search.

Operator	What it does	Example
word1 word2	Implicit AND, both words required	nasa space
word1 OR word2	Either word (OR must be UPPERCASE)	nasa OR spacex
"exact phrase"	Exact phrase match (also disables spell-correction)	"state of the art"
"phrase with * wildcard"	Wildcard inside quoted phrase	"this is the * time"
+term	Force exact term, disable spell-correction	+radiooooo
-term	Exclude term	crypto -bitcoin
-"phrase"	Exclude phrase	-"live laugh love"
#hashtag	Match hashtag	#web3
$TICKER	Cashtag (stock ticker)	$TSLA
url:domain.com	Match tokenized URL in tweet	url:youtube.com
:) or :(	Positive/negative emoticon sentiment	iphone :(

Tip: The AND operator is implicit. Writing (nasa esa) and nasa esa returns the same results.

Tip: For domains with hyphens, replace hyphens with underscores: url:t_mobile.com.

---

2. User Filters

User filters restrict results by author, mention target, or account type. from: matches tweets authored by the account, to: matches direct replies to that account, and @ matches any tweet that mentions them. filter:verified matches legacy verified accounts and filter:blue_verified matches X Premium subscribers.

Filter by who sent the tweet or who's mentioned.

Operator	What it does	Example
from:username	Tweets authored by user	from:elonmusk
to:username	Replies directed at user	to:elonmusk
@username	Tweet mentions user (author or reply)	@elonmusk
@username -from:username	Mentions-only (excluding their own tweets)	@elonmusk -from:elonmusk
list:handle/listname	Tweets from list members	list:nasa/astronauts
list:<listId>	Tweets from list by numeric ID	list:715919216927322112
filter:verified	Legacy verified accounts	AI filter:verified
filter:blue_verified	X Premium (paid) verified	AI filter:blue_verified
filter:follows	Only accounts you follow	crypto filter:follows

Note: list: and filter:follows cannot be negated. You can't write -list:nasa/astronauts.

Note: To isolate legacy (pre-Blue) verified accounts, combine: filter:verified -filter:blue_verified.

---

3. Date and Time Filters

Date and time filters make Twitter search far more precise. since:YYYY-MM-DD and until:YYYY-MM-DD set inclusive/exclusive day boundaries, full timestamp variants add hour and minute precision, and within_time: provides a rolling window relative to the query time. Date filters must be combined with at least one other operator to return results.

This is where programmatic search gets powerful, especially for dealing with Twitter's broken pagination (more on that below).

Operator	What it does	Example
since:YYYY-MM-DD	On or after date (inclusive)	since:2025-01-31
until:YYYY-MM-DD	Before date (exclusive)	until:2025-12-31
since:YYYY-MM-DD_HH:MM:SS_UTC	Precise timestamp with timezone	since:2025-01-31_12:00:00_UTC
since_time:<unix>	Unix epoch seconds start	since_time:1700000000
until_time:<unix>	Unix epoch seconds end	until_time:1700086400
since_id:<tweet_id>	From tweet ID onward (uses Snowflake ordering)	since_id:1234567890
max_id:<tweet_id>	Up to tweet ID	max_id:1234567890
within_time:2d	Rolling window (2 days)	bitcoin within_time:2d
within_time:3h / 5m / 30s	Hours / minutes / seconds	within_time:5m

Critical caveat: Time operators must be combined with another operator. since:2025-01-01 alone won't work; pair it with a keyword, user, or hashtag.

Time precision tip: If results are changing by the minute (trending topics, breaking news), use _HH:MM:SS_UTC format to get sub-hour granularity.

---

4. Engagement Filters (Watch the Operator Names)

Engagement filters set thresholds on likes, reposts, and replies. Both operator sets support the capability, but the names differ, and this is the single most common cause of a 400 error when moving a query from the search box to the official API.

On web search the names are min_faves: and min_retweets:. On the official X API the equivalents are min_likes: and min_reposts:, and X's operator reference states plainly that the web names "are not valid in the X API and will be rejected with a 400 error." min_replies: is spelled the same on both.

Web search name	Official X API name
min_faves:N	min_likes:N
min_retweets:N	min_reposts:N
min_replies:N	min_replies:N (same)

The table below uses the web names, since that is what this guide documents. Translate them if you are sending the query to the official API.

Operator	What it does	Example
min_faves:N	At least N likes	AI min_faves:1000
min_retweets:N	At least N retweets	crypto min_retweets:100
min_replies:N	At least N replies	bitcoin min_replies:50
-min_faves:N	Less than N likes (max threshold)	-min_faves:10
-min_retweets:N	Less than N retweets	-min_retweets:5
-min_replies:N	Less than N replies	-min_replies:0
filter:has_engagement	Any engagement (likes, RTs, replies, quotes)	from:elonmusk filter:has_engagement
-filter:has_engagement	Zero-engagement tweets	from:me -filter:has_engagement

Real-world example: Find viral tweets from any account about AI in 2026: AI since:2026-01-01 min_faves:5000 lang:en.

---

5. Tweet Type Filters

Tweet type filters separate original content, replies, retweets, quote-tweets, and thread self-replies. filter:replies matches any reply, -filter:replies strips replies out of results, and conversation_id: retrieves every tweet in a specific thread by its root tweet ID.

Filter by whether it's a reply, retweet, quote, or part of a thread.

Operator	What it does
filter:replies	Tweet is a reply
-filter:replies	Exclude replies
filter:self_threads	Self-reply threads (Twitter threads)
filter:quote	Tweet contains a quoted tweet
filter:retweets	Old-style "RT" + quote tweets
filter:nativeretweets	RT-button retweets (only last 7-10 days)
include:nativeretweets	Include retweets (excluded by default)
conversation_id:<tweet_id>	All tweets in a specific conversation
quoted_tweet_id:<tweet_id>	Tweets quoting a specific tweet
quoted_user_id:<user_id>	Tweets quoting a specific user

Note: filter:nativeretweets and include:nativeretweets only work for approximately the last 7-10 days. For older retweets, use filter:retweets.

---

6. Media Filters

Media filters narrow results to tweets with specific attachment types. filter:media catches any media, filter:images matches any image source, filter:native_video limits to Twitter-hosted video, and filter:links matches any tweet containing a URL. These can be negated to exclude a media type or combined to isolate a specific format.

Filter by attached media type.

Operator	What it does
filter:media	Any media attached
filter:images	Has an image (any source)
filter:twimg	Native Twitter images only (pic.twitter.com)
filter:videos	Any video (including YouTube embeds)
filter:native_video	Twitter-hosted video
filter:consumer_video	Standard native Twitter video
filter:pro_video	Amplify / pro video
filter:spaces	Twitter Spaces (audio)
filter:links	Any URL
filter:hashtags	Contains a hashtag
filter:mentions	Contains an @mention
filter:news	Links to whitelisted news domains
filter:safe	Excludes NSFW/sensitive content

Useful combo: from:NASA filter:media -filter:images, all NASA media except images (i.e., videos and GIFs).

---

7. Language Filters

Language filters use ISO 639-1 two-letter codes to restrict results by Twitter's auto-detected tweet language. lang:en for English, lang:es for Spanish, lang:ja for Japanese. Twitter also exposes undocumented pseudo-language codes like lang:zxx for media-only tweets and lang:qht for hashtag-only tweets, which are useful for removing text noise from media-focused searches.

Operator	What it does
lang:en	English
lang:es	Spanish
lang:ja	Japanese
lang:hi	Hindi
lang:fr, lang:de, lang:pt, lang:ru, lang:zh, lang:ar, lang:ko, etc.	ISO 639-1 two-letter codes

Special pseudo-languages (rarely documented)

These are unique Twitter codes that classify tweets by content type rather than language:

Code	Matches tweets that contain only
lang:und	Undefined / unclassifiable language
lang:qam	@mentions (no other content)
lang:qct	Cashtags (no other content)
lang:qht	Hashtags (no other content)
lang:qme	Media links (no other content)
lang:qst	Very short text (usually <3 chars)
lang:zxx	Media/cards with no text

Why this matters: Want to find tweets that are just an image and nothing else? Use from:user lang:zxx filter:images. Zero noise.

---

8. Geo Filters

Geo filters match tweets by attached location data. near:"City Name" matches tweets geotagged to that city, geocode:lat,lng,radius matches a coordinate circle, and within: adds a radius to a near: query. As of 2026, exact-coordinate geotagging is deprecated for most text tweets, so geo filters have significantly reduced coverage and should not be the primary filter on any query.

Operator	What it does
near:"City Name"	Geotagged in city
near:me	Near your location
within:10km	Radius modifier (km or mi)
geocode:37.7764,-122.4172,10km	Lat/long/radius
place:<Place ID>	Twitter Place Object

Warning: Twitter phased out exact-coordinate geotagging for most text tweets. Geo operators now have significantly reduced coverage and should not be relied upon for comprehensive results.

---

9. App / Source Filters

App and source filters match tweets by the client that posted them. source:twitter_for_iphone matches iPhone-posted tweets, source:twitter_web_app matches web posts, and source:twitter_ads isolates promoted tweets. Replace all spaces and hyphens with underscores in the source name string.

Filter by which client posted the tweet.

Operator	What it does
source:twitter_for_iphone	Posted from iPhone
source:twitter_for_android	Posted from Android
source:twitter_web_app	Posted from web
source:tweetdeck	Posted from TweetDeck
source:twitter_ads	Paid promoted tweet

Syntax note: Replace spaces and hyphens with underscores. Twitter for iPhone becomes twitter_for_iphone.

---

10. Combining operators (examples)

Combining operators is where Twitter search becomes genuinely powerful. A query like AI min_faves:5000 lang:en since:2026-01-01 filters by topic, engagement floor, language, and date simultaneously. Operator combinations can target viral tweets from specific verified accounts, public discussion around any ticker, or complete threads by conversation ID.

The real power is in combinations. Here are examples of high-signal queries:

Query	What it finds
from:elonmusk min_faves:50000 since:2026-01-01	Elon's most viral 2026 tweets
(bitcoin OR eth) min_faves:1000 lang:en -filter:retweets	Popular English crypto tweets (no RTs)
"$NVDA" filter:blue_verified min_replies:20	NVDA discussion from verified users with engagement
#AI filter:images min_faves:100 since:2026-01-01	Popular AI tweets with images in 2026
from:NASA filter:media -filter:images	NASA videos and GIFs
list:nasa/astronauts since:2026-01-01 lang:en	Recent tweets from astronaut list
to:openai min_faves:10	Engaging replies directed at OpenAI
conversation_id:1234567890	Full thread around a tweet

---

Operators that are unreliable or broken in 2026

Several operators in the reference lists are historically valid but unreliable in 2026. filter:vine and filter:periscope are historical only since those platforms shut down. Geo operators have reduced coverage because X deprecated exact-coordinate geotagging. filter:nativeretweets works only for the last 7 to 10 days. And Twitter silently ignores queries longer than 22 to 23 operators total.

Knowing what doesn't work saves hours of debugging:

Operator	Status	Why
filter:vine	Historical only	Vine shut down in 2017
filter:periscope	Historical only	Periscope shut down in 2021
near:, within:, geocode:	Reduced coverage	Exact geo deprecated for most tweets
filter:nativeretweets	7-10 day window only	Twitter's retention limit
card_name:*	7-8 day window only	Short retention
filter:verified	Behaves inconsistently	Conflated with Blue post-rebrand

Operator cap: Twitter limits you to approximately 22-23 operators per query. Longer queries silently fail.

---

Running These Operators From Code

The operator string is the same whether you type it into the search box or send it to an API; only the transport changes. The examples below send an operator string to an endpoint that passes the full web operator set through, so every filter documented above works unchanged. For endpoint parameters, pagination behavior, and pricing, see the Twitter search API page and the advanced search endpoint docs.

The only thing to get right on the wire is encoding: q takes the operator string URL-encoded, so min_faves:1000 becomes min_faves%3A1000 and spaces become +. Everything else is a normal authenticated GET.

curl

curl "https://api.getxapi.com/twitter/tweet/advanced_search?q=AI+min_faves%3A1000+since%3A2026-01-01&product=Latest" \
  -H "Authorization: Bearer YOUR_API_KEY"

Python

import requests

API_KEY = "YOUR_API_KEY"

resp = requests.get(
    "https://api.getxapi.com/twitter/tweet/advanced_search",
    params={
        "q": "AI min_faves:1000 since:2026-01-01",
        "product": "Latest",
    },
    headers={"Authorization": f"Bearer {API_KEY}"},
)
data = resp.json()
print(f"{len(data['tweets'])} tweets, has_more={data.get('has_more')}")

JavaScript / Node.js

const params = new URLSearchParams({
  q: "AI min_faves:1000 since:2026-01-01",
  product: "Latest",
});

const res = await fetch(
  `https://api.getxapi.com/twitter/tweet/advanced_search?${params}`,
  { headers: { Authorization: `Bearer ${API_KEY}` } }
);
const data = await res.json();
console.log(`${data.tweets.length} tweets, has_more=${data.has_more}`);

The response returns a standard { tweets: [...], next_cursor, has_more } shape, same fields as the official API. To paginate, pass the previous response's next_cursor as the cursor param on the next call.

---

The date-range chunking workaround

As of 2026, Twitter's cursor pagination for Advanced Search is broken upstream. Deep pagination, pulling 10+ pages of results, often returns duplicates or stops early. This isn't a GetXAPI issue; it's a Twitter-side bug that every scraping API inherits.

The workaround: Don't rely on deep pagination. Split your query into date-range chunks instead.

Instead of one big query that paginates for 50 pages, run multiple smaller queries each covering a shorter time range:

• q=AI min_faves:100 lang:en since:2026-01-01 until:2026-01-08
• q=AI min_faves:100 lang:en since:2026-01-08 until:2026-01-15
• q=AI min_faves:100 lang:en since:2026-01-15 until:2026-01-22

Each chunk gets a fresh cursor chain. For rapidly changing results, drop to hourly chunks using full timestamp precision: since:2026-01-01_12:00:00_UTC until:2026-01-01_13:00:00_UTC.

This pattern is more reliable than deep pagination and gives you predictable, reproducible results.

---

Quick reference cheat sheet

The six operator categories developers use most are user filters (from:, to:, @, list:), date filters (since:, until:, within_time:), engagement filters (min_faves:, min_retweets:, min_replies:), content type filters (filter:replies, filter:media, filter:quote), language (lang:en, lang:zxx), and exclusions (-word, -"phrase", -filter:retweets).

Most-used for developers:

• User: from:, to:, @, list:
• Date: since:, until:, within_time:
• Engagement: min_faves:, min_retweets:, min_replies:
• Type: filter:replies, filter:media, filter:quote
• Language: lang:en, lang:zxx (media-only)
• Exclude: -word, -"phrase", -filter:retweets

Hot combo for lead generation:

#yourkeyword min_faves:10 lang:en -filter:retweets since:2026-01-01

Hot combo for sentiment analysis:

$TICKER (":)" OR ":(") min_faves:5 lang:en since:2026-01-01

Hot combo for competitor monitoring:

@competitor -from:competitor filter:has_engagement since:2026-01-01

---

Advanced Code Patterns

Three production patterns cover the most common advanced requirements: a fully paginated search function with exponential backoff on 429 and 5xx errors, a date-range chunker that splits long-window queries into weekly batches to avoid Twitter's cursor-stability bug, and an async concurrent fetcher using httpx that runs multiple date chunks in parallel.

Beyond the basic curl, Python, and JavaScript examples above, here are production patterns for common tasks.

Full paginated search with retry (Python)

import requests
import time

API_KEY = "YOUR_API_KEY"

def search_all_pages(query: str, max_pages: int = 20) -> list[dict]:
    """Paginate through all results with exponential backoff on transient errors."""
    all_tweets = []
    cursor = None
    headers = {"Authorization": f"Bearer {API_KEY}"}

    for page in range(max_pages):
        params = {"q": query, "product": "Latest"}
        if cursor:
            params["cursor"] = cursor

        for attempt in range(3):
            r = requests.get(
                "https://api.getxapi.com/twitter/tweet/advanced_search",
                params=params,
                headers=headers,
                timeout=15,
            )
            if r.status_code == 200:
                break
            if r.status_code in (429, 502, 503):
                time.sleep(2 ** attempt)
            else:
                r.raise_for_status()

        data = r.json()
        all_tweets.extend(data.get("tweets", []))

        if not data.get("has_more"):
            break
        cursor = data.get("next_cursor")

    return all_tweets

# Usage: all viral AI tweets from Jan 2026
tweets = search_all_pages("AI min_faves:1000 lang:en since:2026-01-01 until:2026-02-01")
print(f"{len(tweets)} tweets fetched")

Date-range chunking (Python)

from datetime import date, timedelta

def chunked_search(query_base: str, start: date, end: date, chunk_days: int = 7) -> list[dict]:
    """Split a long-range query into weekly chunks to avoid cursor-stability issues."""
    all_tweets = []
    current = start

    while current < end:
        chunk_end = min(current + timedelta(days=chunk_days), end)
        full_q = f"{query_base} since:{current.isoformat()} until:{chunk_end.isoformat()}"
        batch = search_all_pages(full_q, max_pages=5)
        all_tweets.extend(batch)
        current = chunk_end

    return all_tweets

results = chunked_search("openai min_faves:500 lang:en", date(2026, 1, 1), date(2026, 4, 1))
print(f"Q1 2026: {len(results)} viral OpenAI tweets")

Async concurrent chunks (Python + httpx)

import asyncio
import httpx
from datetime import date, timedelta

API_KEY = "YOUR_API_KEY"

async def fetch_chunk(client: httpx.AsyncClient, query: str) -> list[dict]:
    r = await client.get(
        "https://api.getxapi.com/twitter/tweet/advanced_search",
        params={"q": query, "product": "Latest"},
        headers={"Authorization": f"Bearer {API_KEY}"},
    )
    r.raise_for_status()
    return r.json().get("tweets", [])

async def parallel_date_search(base_q: str, start: date, num_weeks: int = 4) -> list[dict]:
    queries = []
    for i in range(num_weeks):
        s = start + timedelta(weeks=i)
        e = s + timedelta(weeks=1)
        queries.append(f"{base_q} since:{s.isoformat()} until:{e.isoformat()}")

    async with httpx.AsyncClient(timeout=15) as client:
        results = await asyncio.gather(*[fetch_chunk(client, q) for q in queries])

    return [t for batch in results for t in batch]

tweets = asyncio.run(parallel_date_search("bitcoin min_faves:200 lang:en", date(2026, 1, 1), num_weeks=12))
print(f"{len(tweets)} tweets across 12 weeks, fetched concurrently")

---

Practical Use Cases by Operator Set

Individual operators become high-value tools when combined for specific research tasks. The five most common production use cases are brand monitoring (company name plus engagement floor, excluding own posts), influencer discovery (niche keyword plus verified filter and engagement minimum), competitor intelligence (competitor name minus their own posts), historical event research (keyword with hourly date-range chunks), and thread reconstruction (conversation_id plus quote-tweet filters).

Understanding individual operators is only half the picture. Here is how teams combine them in production.

Use case 1: Brand monitoring

Track what people say about your brand in real time, filtered to meaningful engagement and excluding your own posts:

"YourBrand" OR "@yourhandle" min_faves:5 lang:en -from:yourhandle -filter:retweets since:2026-01-01

Break this into weekly chunks and run it on a cron job. Store each result set in a database with the query date. Compare week-over-week to spot sentiment shifts before they become a PR problem. If you need to score sentiment on the results, the Twitter sentiment analysis guide covers exactly this pipeline.

Use case 2: Influencer discovery

Find accounts posting high-engagement content in a specific niche with verified status:

#niche OR "keyword1" OR "keyword2" min_faves:500 min_retweets:100 lang:en filter:blue_verified -filter:retweets since:2026-01-01

The min_faves:500 min_retweets:100 floor removes noise. filter:blue_verified limits results to accounts with a paid verification tier. Paginate through the results, extract the author.userName from each tweet, and you have a seed list of high-signal accounts in the niche. The Python Twitter API tutorial has the pagination code for this pattern.

Use case 3: Competitor intelligence

Monitor what people say about a competitor without including the competitor's own posts:

"CompetitorName" OR "@competitor" -from:competitor min_faves:10 lang:en -filter:retweets

Add filter:replies to isolate complaint threads. Add -filter:replies to see organic mentions. The engagement floor (min_faves:10) removes random noise and low-signal posts that would dilute the signal.

Use case 4: Historical event research

Reconstruct public reaction to a product launch, news event, or market move using date-range chunking:

"event keyword" lang:en since:2026-03-01 until:2026-03-02
"event keyword" lang:en since:2026-03-02 until:2026-03-03
... (hourly if volume is high)

The until: date in each chunk is the exclusive upper bound. For sub-hour granularity during fast-moving events, use the timestamp format: since:2026-03-01_09:00:00_UTC until:2026-03-01_10:00:00_UTC. This reconstructs the exact sequence of public reaction hour by hour. For the cost math on large historical sweeps, see the Twitter API cost guide.

Use case 5: Scraping a specific Twitter thread

If you know a tweet's ID and want all replies and quote-tweets:

conversation_id:1234567890

And for all tweets quoting a specific tweet:

quoted_tweet_id:1234567890

Combine with min_faves:5 to filter the thread to meaningful engagement only. This is useful for capturing full public reactions to a specific post, something the official X API requires multiple separate calls to reconstruct.

---

Start using these operators

The web operator set documented here is broader than the official X API vocabulary: within_time:, filter:blue_verified, the app-source filters, and several media and geo filters have no API equivalent, and the engagement filters use different names on each side. To try the operators against a live index, any provider that accepts the full web set will do; endpoint options and pricing are on the Twitter search API page.

1. Sign up at getxapi.com, instant API key, no developer account needed
2. Call GET /twitter/tweet/advanced_search with your operator query in the q parameter
3. Read the full API docs for pagination, rate limits, and response schema

For the complete operator reference (including obscure ones this guide doesn't cover), check the community-maintained twitter-advanced-search repository on GitHub. For production-grade scraping patterns including cost optimization and proxy strategy, see the Twitter scraping best practices guide. For a full comparison of what the official X API supports versus GetXAPI's operator set, the Twitter API v2 vs GetXAPI guide covers that in detail. Pricing for advanced search calls at scale is broken down in the Twitter API cost guide.

Operator Testing Workflow

The reliable workflow for validating any new operator combination before using it in production has three steps: test the query syntax on Twitter web search to confirm results match intent at zero API cost, make one live API call and inspect the first five tweet texts to catch semantic mismatches, and check has_more on the first response to diagnose queries that are too narrow before running a full paginated job.

Before using a new operator combination in a production pipeline, test it manually in three steps.

Step 1: Validate the syntax on Twitter web search. Open twitter.com/search, paste the query, and confirm you get results that match your intent. Twitter's web search uses the same web-search operator set as GetXAPI, so this is a free validation layer before you spend any API credits.

Step 2: Test via a single API call. Run one call with the operator string and inspect the response. Look at the first 5 tweet texts and confirm they match what you expect. This catches semantic mismatches where the syntax is valid but the query logic is wrong.

Step 3: Check result count before paginating. On the first call, look at has_more and next_cursor. If has_more is false and you got fewer than 5 results, the query is either too narrow or the time window is wrong. Adjust before running a full paginated job.

This three-step process prevents the most common data-quality issue in operator-driven scrapers: a valid-looking query that returns empty or off-target results at scale.

---

Frequently Misunderstood Operators

Four operators behave differently than their names imply: filter:blue_verified matches X Premium paying subscribers, not legacy-verified editorial accounts; -filter:retweets removes both old-style RT text and native retweets; within_time: is a rolling window from query time, not a fixed date anchor; and @user matches any mention of the account, not just replies, so it needs a language or engagement filter to reduce noise.

A few operators behave differently than their names suggest.

filter:blue_verified vs filter:verified: filter:verified matches accounts with the pre-Blue legacy verification (journalists, celebrities, organizations who were verified before 2023). filter:blue_verified matches X Premium (paid) subscribers. Most brand-monitoring queries want filter:verified for editorial signal, not filter:blue_verified which includes any paying user.

-filter:retweets vs include:nativeretweets: -filter:retweets excludes both old-style manual "RT @user" text and native retweet-button retweets. include:nativeretweets adds native retweets back in (they are excluded by default on most queries). For a clean dataset of original content only, use -filter:retweets. For tracking how far a specific tweet spread, use filter:nativeretweets with a narrow time window.

within_time:Xd: Rolling windows (within_time:7d) are calculated from the moment of the query, not from a fixed date. This means the same query returns different tweet sets if you run it today versus next week. For reproducible research datasets, use explicit since: and until: date operators instead.

from:user vs @user: from:user returns only tweets authored by the account. @user returns any tweet that mentions the account, including replies from others and quote-tweets. Use from:user for timeline analysis, @user for mention monitoring, and combine them with OR for full context. Note that @user on its own can return unrelated tweets if the handle is a common word, so add a language filter (lang:en) or engagement floor (min_faves:1) to reduce noise in high-volume mention streams.

---

Operator reference data sourced from the community-maintained igorbrigadir/twitter-advanced-search repository (updated regularly), the official X API documentation as of May 2026, and the X Developer Community forums for operator behavior updates.