Twitter Search Operators 2026: Complete Cheat Sheet & API

Last verified: May 2026. Author: Daniel Kolbassen, Data Engineer & API Infrastructure Consultant.

If you have ever tried to monitor a brand mention, find tweets from a specific date range, or pull viral posts about a topic, you have probably hit the same wall: X's basic search bar dumps a firehose of mostly irrelevant results, and the official X advanced search UI hides most of the real power. The good news is that almost every powerful filter you would actually want exists as a text operator you can type into the search bar, paste into TweetDeck, or pass programmatically to an API.

This guide is built for two readers: the marketer who wants copy-paste queries that just work, and the developer who needs to run those queries at scale. The Sorsa Search Tweets API supports the full web operator set, so every operator below works in production code, not just on x.com. If you have ever tried to use the official X API v2 and wondered why min_faves: or filter:blue_verified did nothing, that is the central pain point we will unpack: web search operators and official X API v2 operators are not the same thing, and the difference matters.

For credit where it is due: this guide draws heavily on real-world testing plus the comprehensive twitter-advanced-search reference maintained by Igor Brigadir, which is the de facto industry source on undocumented X search behavior.

Table of Contents

1. How X search operators work
2. Web operators vs official X API v2 operators
3. Keyword, phrase, and Boolean logic
4. User and account filters
5. Engagement gating
6. Media and content type filters
7. Date, time, and Snowflake IDs
8. Geographical filters
9. Language and source filters
10. Card and URL operators
11. Cookbook: 14 production-ready recipes
12. Using operators with the Sorsa API
13. Building complex queries: order of operations
14. Known limitations and gotchas
15. FAQ

How X Search Operators Work

X search operators are small text commands you append to a query to filter the result set. They work in three places: the X.com search bar, TweetDeck, and any third-party API that passes the full web search syntax through (such as the Sorsa Search Tweets endpoint). The syntax is operator:value with no space around the colon, and operators can be combined freely.

Operators fall into two broad categories. Standalone operators can be used on their own (for example from:elonmusk returns a valid result set). Conjunction-required operators must appear alongside at least one standalone operator, because they would otherwise match too much content. This distinction matters more on the official X API v2 than on the web, but it is worth understanding from the start.

Three universal rules:

• AND is implicit. Putting two terms next to each other (bitcoin etf) requires both.
• OR must be uppercase. Lowercase or is treated as a literal word.
• Exclusion uses a leading dash. crypto -scam removes results containing "scam".

If you are going to use these in production, bookmark the Sorsa Search Builder. It is a free no-login tool that lets you toggle filters visually and generates a copy-ready query string with full operator coverage. It is the fastest way to prototype before integrating into code.

Web Operators vs Official X API v2 Operators

This is the single most important thing most cheat sheets do not tell you. The X advanced search syntax that works on x.com is a superset of the operator list supported by the official X API v2 search endpoint. If you build a production pipeline on /2/tweets/search/recent and pass it min_faves:100 since:2026-01-01 filter:blue_verified, none of those three operators do anything. They are not errors. They are silently dropped.

I have seen this exact bug in three migration projects since 2024. The query "works", in the sense that it returns tweets, but the filtering you thought you had is gone. By the time someone notices, the analytics dashboard has been wrong for weeks.

Here is the operator-by-operator comparison for the ones developers actually care about:

The biggest casualties for real work are the engagement filters (min_faves, min_retweets, min_replies) and the rich date syntax. Without min_faves:, you cannot efficiently surface viral or influential content on the API v2 side. You can pull tweets and filter client-side, but on high-volume queries you end up burning your quota on tweets you immediately discard. The cost difference compounds fast.

The official X API v2 also imposes hard character limits on the query itself: 512 characters for self-serve recent search, 1,024 for full-archive, and 4,096 only at enterprise tier. Web syntax and Sorsa's pass-through have no such limit beyond the practical operator cap of around 22-23 operators per query.

Disclosure: Sorsa API is our product. We have aimed to keep this comparison strictly factual; the missing-operator list is verifiable against X's own public docs on the day this article was published. For a deeper look at migration tradeoffs, see our migration guide from the official X API.

Keyword, Phrase, and Boolean Logic

These are the building blocks. Every advanced query starts here.

A few practical notes that trip people up. Plurals match their singulars and vice versa: bulls will match bull. X sometimes silently re-interprets common words as content intent, so searching photo may return tweets with attached images even if the word "photo" is absent in the text. Wrap such words in double quotes to force a literal match. Operators are not strictly bound to the tweet body either: they can match against the author's display name, screen name, and expanded URLs inside the tweet, which is a frequent source of surprising results.

The cap on operator count is real. Once you cross roughly 22-23 operators in a single query, X starts ignoring trailing parts of the string silently. If you need more than that, split into multiple API calls and merge results downstream.

User and Account Filters

These filter tweets by who posted, who they reply to, or who is mentioned.

Brand monitoring trick. Combine from: with -from: to find what everyone except the brand itself says about the brand: "Tesla" -from:tesla. This single move is the difference between actionable signal and PR noise.

If you need a deep dive on tracking mentions specifically, see Track Mentions and our follower extraction guide.

Engagement Gating

Filter by minimum (or maximum) engagement. These are essential for cutting through noise and surfacing viral content. They are also the operators most often missing from the official X API v2.

How to set thresholds. Start low (min_faves:10) and increase iteratively. X reports become approximate above ~1,000, so do not over-tune. Combine with -filter:retweets if you only want tweets that earned engagement on their own content rather than amplification.

In our own pipeline work, the combination min_faves:N + -filter:retweets + -filter:replies is the single most useful filter for surfacing original viral content. Everything else is dressing.

Media and Content Type Filters

X has unusually granular control over what kind of content appears in your results. The catch is that the web operator set is much richer than the API v2 equivalents.

Media filters

Tweet type filters

Special content filters

Date, Time, and Snowflake IDs

Precise time-based filtering is critical for event analysis, campaign tracking, and historical data extraction. This is also where the official X API v2 diverges most sharply: it expects start_time and end_time as separate request parameters and does not understand since: / until: in the query string. Web syntax and Sorsa support the full set.

The Snowflake ID trick

Every tweet ID on X is a Snowflake ID that encodes its creation timestamp at millisecond precision. The conversion formula:

millisecond_epoch = (tweet_id >> 22) + 1288834974657

This is useful for two reasons. First, you can compute the exact post-time of any tweet without making an API call, which is handy for backfill jobs that need to dedupe or order by time. Second, since_id: and max_id: give you tweet-level rather than date-level boundaries on result windows: invaluable when you are paginating a high-volume keyword over hours and want to resume exactly where you left off without re-fetching seen tweets.

For a deeper walkthrough of pulling historical tweet sets, see Historical Data.

Geographical Filters

A reality check before you go deep here: only an estimated 1-2% of tweets carry precise geolocation data. X removed precise location tagging from the main iOS and Android apps in June 2019, and most users never opted in to begin with. Geo filters are still useful, but expect thin coverage.

A useful fallback behavior. If a tweet does not have precise coordinates, the API falls back to reverse-geocoding the user's profile location. So you may receive tweets that match based on the author's stated location, not the tweet's actual origin. This is sometimes what you want and sometimes confusing. For a dedicated approach to mapping audience location by country (which is far higher-coverage than tweet-level geo), see Audience Geography.

Language and Source Filters

Language

X uses 2-letter ISO 639-1 codes: lang:en, lang:es, lang:fr, lang:de, lang:ja, lang:ru, and so on. There are also several non-standard codes worth knowing:

X's language detection is not perfect. Short tweets, code snippets, and emoji-heavy posts are routinely misclassified. For critical applications, run your own language detection on the body text after retrieval.

Source (posting client)

Common values: Twitter_for_iPhone, Twitter_for_Android, Twitter_Web_App, TweetDeck, twitter_ads. Note that source: sometimes needs another operator alongside it to return results.

Card and URL Operators

These match on Twitter Card metadata: the rich previews attached to tweets containing links, media, and embedded content. Two things to know up front: card_name: typically only works for tweets from the last 7-8 days, and url: works well for domains but is unreliable for long URL paths.

Cookbook: 14 Production-Ready Recipes

Operators are useful in isolation. They are powerful in combination. Here are fourteen battle-tested query patterns we have either built ourselves or seen in client pipelines. Copy them, swap the variables, and paste them straight into the X search bar or the Sorsa Search Tweets endpoint.

1. Brand and reputation monitoring

Find original viral content about a brand, excluding the brand's own posts and retweet noise:

("Tesla" OR "Elon Musk") min_faves:500 filter:links lang:en -from:tesla -filter:nativeretweets

2. Competitor lead generation

Find users actively asking about alternatives in your niche:

("notion" OR "obsidian") "?" -filter:links -from:notionhq lang:en

3. High-intent buyer discovery

Find tweets that read like buying signals for a product category:

("looking for" OR "anyone use" OR "recommend") ("twitter api" OR "x api") -filter:retweets lang:en

4. Influencer discovery

High-engagement original posts from verified accounts in a topic:

"machine learning" filter:blue_verified min_faves:200 -filter:replies -filter:retweets lang:en

5. OSINT and breaking news

Track real-time events with visual evidence from verified sources:

"breaking news" filter:images filter:blue_verified within_time:6h

6. Content curation from X Lists

Find viral videos posted by members of a specific List:

list:715919216927322112 (filter:videos OR card_name:animated_gif) min_retweets:50

7. Developer troubleshooting

Find error-related conversations linking to GitHub:

url:github.com "error" lang:en filter:replies

8. Crypto sentiment with engagement gating

Track sentiment-laden conversation about a token, filtered for substance:

(bitcoin OR $BTC) (bullish OR bearish OR crash OR moon) min_faves:20 lang:en since:2026-01-01 -filter:retweets

9. Hyper-local monitoring

What is being said near a specific place in a tight time window:

"traffic" near:"London" within:5km since:2026-03-05_12:00:00_UTC

10. Find quote tweets of a specific user

Pattern-match the URL form and exclude the user's own handle:

twitter.com/elonmusk/status/ -from:elonmusk

11. Original-only thread leaders

Find tweets that started threads (not replies, not retweets) and got real engagement:

"your topic" min_replies:10 -filter:replies -filter:retweets lang:en

12. Track a product launch window

Capture all conversation in a specific date range with engagement floor:

"product name" since:2026-02-10 until:2026-02-17 lang:en min_faves:5

13. Zero-engagement spam detection

Identify suspicious low-quality posting (useful for moderation pipelines):

"buy now" -filter:has_engagement filter:links lang:en

14. Job board mining

Hiring-signal tweets in a specific technical niche:

("hiring" OR "we're looking for") ("react" OR "typescript") -filter:retweets lang:en min_faves:5

The pattern across all fourteen: start with the topic, layer engagement, layer content type, then layer exclusions. The exclusions are usually what separates a noisy result set from a usable one.

Using Operators with the Sorsa API

Every operator listed above works in the query field of the Sorsa /v3/search-tweets endpoint. Pass your full query string as the body of a POST request, paginate via next_cursor, and handle 429s with a brief retry.

A minimal call with curl:

curl -X POST https://api.sorsa.io/v3/search-tweets \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "(AI OR \"machine learning\") min_faves:100 lang:en -filter:retweets",
    "order": "popular"
  }'

Python: production-ready with pagination and retry

This is the pattern we run in production. It paginates the full result set, retries on rate limiting, and surfaces hard errors:

import requests
import time
from typing import Iterator

API_KEY = "YOUR_SORSA_API_KEY"
BASE_URL = "https://api.sorsa.io/v3/search-tweets"


def search_tweets(query: str, order: str = "latest") -> Iterator[dict]:
    """
    Paginate through every tweet matching the query.
    Retries on 429 (rate limit) with a 1-second wait.
    """
    cursor = None
    while True:
        payload = {"query": query, "order": order}
        if cursor:
            payload["next_cursor"] = cursor

        response = requests.post(
            BASE_URL,
            headers={
                "ApiKey": API_KEY,
                "Content-Type": "application/json",
            },
            json=payload,
            timeout=30,
        )

        if response.status_code == 429:
            time.sleep(1.0)
            continue

        response.raise_for_status()
        data = response.json()

        for tweet in data.get("tweets", []):
            yield tweet

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


if __name__ == "__main__":
    query = (
        '("openai" OR "anthropic") min_faves:50 lang:en '
        '-filter:retweets since:2026-05-01'
    )
    for i, tweet in enumerate(search_tweets(query), 1):
        author = tweet["user"]["username"]
        text = tweet["full_text"][:120].replace("\n", " ")
        print(f"{i:4d}. @{author}: {text}")
        if i >= 200:
            break

JavaScript / Node.js: async iterator pattern

const API_KEY = "YOUR_SORSA_API_KEY";
const BASE_URL = "https://api.sorsa.io/v3/search-tweets";

async function* searchTweets(query, order = "latest") {
  let cursor = null;
  while (true) {
    const body = { query, order };
    if (cursor) body.next_cursor = cursor;

    const response = await fetch(BASE_URL, {
      method: "POST",
      headers: {
        "ApiKey": API_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(body),
    });

    if (response.status === 429) {
      await new Promise((r) => setTimeout(r, 1000));
      continue;
    }
    if (!response.ok) {
      throw new Error(`Sorsa search failed: ${response.status}`);
    }

    const data = await response.json();
    for (const tweet of data.tweets || []) {
      yield tweet;
    }

    cursor = data.next_cursor;
    if (!cursor) break;
  }
}

// Usage
(async () => {
  const query =
    '("openai" OR "anthropic") min_faves:50 lang:en ' +
    '-filter:retweets since:2026-05-01';

  let count = 0;
  for await (const tweet of searchTweets(query)) {
    count += 1;
    const text = tweet.full_text.slice(0, 120).replace(/\n/g, " ");
    console.log(`${count}. @${tweet.user.username}: ${text}`);
    if (count >= 200) break;
  }
})();

A few things worth flagging about this pattern. The rate limit for a single API key is 20 requests per second, universal across plans, so the 1-second backoff on 429 is almost always more than enough. If you are running aggressive parallel jobs across many keywords, consider widening the backoff to 2-3 seconds or batching with a token bucket. For long-running scrapes, persist cursor between runs so you can resume cleanly. For more on optimizing query throughput, see our notes on optimizing API usage and pagination.

If you would rather skip the code entirely, the Sorsa Playground runs the same endpoint with CSV and JSON export, no coding required. The Search Builder is the front-door tool for assembling complex queries visually.

Building Complex Queries: Order of Operations

Once you start stacking five or six operators, the order they are evaluated in starts to matter. The rule on X is the same as on most search engines: AND binds tighter than OR.

That means cat OR black dog is evaluated as cat OR (black dog), not (cat OR black) dog. If you want the second interpretation, parenthesize: (cat OR black) dog. When in doubt, use parentheses. They cost you nothing and they eliminate ambiguity.

A practical construction order that works for almost every query:

1. Group core keywords in parentheses: (bitcoin OR ethereum OR $BTC)
2. Add content constraints: lang:en, filter:images, -filter:replies
3. Set engagement thresholds: min_faves:50, min_retweets:10
4. Exclude noise: -from:spambot, -scam, -airdrop, -filter:retweets
5. Add time bounds if needed: since:2026-01-01 until:2026-03-01

If you follow this order consistently, you can read any of your queries at a glance and spot mistakes faster.

Known Limitations and Gotchas

Things that will eventually bite you if you do not know about them up front:

• Operator cap: queries support roughly 22-23 operators maximum. Cross that and the trailing part of the query is silently ignored.
• Geo coverage is thin: only 1-2% of tweets have precise location data. Most queries with near: or geocode: rely on profile-location fallback, which is not the same thing.
• card_name: is time-limited: typically only the past 7-8 days return results.
• Private and suspended accounts are excluded from all search results. You cannot reach them with operators.
• Language detection is imperfect. Short tweets, code snippets, and emoji-heavy posts get misclassified routinely.
• Not all tweets are indexed. Posts flagged for platform violations or anti-spam reasons are excluded from search even if technically still on the platform. This is a known gap when chasing engagement-blocked accounts (see our writeup on Twitter's "this request looks like automated" error for related context).
• Auto-correction happens silently in some cases. Use +word or "word" to force exact matching.
• URL matching is fragile. Domains and subdomains work, but long URL paths are unreliable, and hyphens in domains must be replaced with underscores (e.g., url:t_mobile.com).
• Official X API v2 silently drops half the operators above. Already covered, but worth repeating. If you are debugging missing results on an API v2 pipeline, this is usually why.

FAQ

What is X advanced search?

X advanced search is the platform's built-in tool for filtering tweets using specific criteria like author, date, engagement, media type, and language. It is accessible at x.com/search-advanced as a graphical form, or you can type operators directly into the search bar from anywhere. Operators are usually faster once you know them.

How do I search Twitter by date?

Use since:YYYY-MM-DD and until:YYYY-MM-DD together. Example: "product launch" since:2026-02-10 until:2026-02-17. The since: date is inclusive; until: is exclusive (the tweet must be posted before that date, not on it). For sub-day precision, use the timestamp form: since:2026-02-10_14:00:00_UTC.

How do I find old tweets without a Twitter account?

In 2026, X requires login for most search functionality, including the basic search bar. You have two practical options: use the Internet Archive's Wayback Machine for specific tweet URLs you already know, or use a third-party API like Sorsa that maintains its own access path to X's public search index. For broader scraping context, see our guide to scraping Twitter.

Can you search for deleted tweets?

No. Once a tweet is deleted, X removes it from the search index, and no operator combination will surface it. The same applies to tweets from accounts that have been suspended or made private after the fact. If you need to preserve potentially-deleted content, you need to archive it at collection time. The Sorsa tweet-info-bulk endpoint lets you snapshot up to 100 tweets per call for archival pipelines.

How do I access advanced search on the X mobile app?

The graphical advanced search form is web-only and not available in the mobile app. However, every operator in this guide can be typed directly into the mobile app's search bar. Once you know the syntax, the mobile experience is functionally identical to the web one.

Why isn't my search operator working on the official X API?

Almost certainly because you are using a web-syntax operator that the official X API v2 does not support. The most common culprits are min_faves:, min_retweets:, since:, until:, within_time:, filter:blue_verified, and card_name:. The API v2 silently drops these instead of throwing an error. See the web vs API v2 comparison table above for the full list. Sorsa accepts the full web operator set, which is why most teams running production pipelines on top of these operators end up on a third-party API.

How many search operators can I combine in one query?

Roughly 22-23 before X starts ignoring trailing operators. On the official X API v2 you also hit a hard character limit on the query string: 512 characters for self-serve recent search, 1,024 for full-archive, and 4,096 only at enterprise tier. On Sorsa, you are bounded only by the practical operator cap, not by character count.

What's the difference between filter:retweets and -is:retweet?

filter:retweets is the web syntax; -is:retweet is the official X API v2 syntax for the inverse (excluding retweets). They are not perfectly equivalent: filter:retweets historically includes both old-style RT retweets and quote tweets, while is:retweet in the API v2 is narrower. If you want to exclude every form of amplification cleanly on the web side, use -filter:retweets -filter:quote together.

Source and Acknowledgments

This guide draws on the maintained twitter-advanced-search repository by Igor Brigadir, which is the industry-standard reference for X search logic, Snowflake ID mechanics, and undocumented operator behaviors. We have cross-checked every operator listed here against current X behavior as of May 2026, plus the official X API v2 operator list and build-a-query guide.

Try It Yourself

The fastest way to put this cheat sheet to work:

1. Open the Sorsa Search Builder and assemble a query visually. No login, no rate limit on building.
2. Run it in the Sorsa Playground to see real results with CSV and JSON export. Same, no login required for the builder portion.
3. When you are ready to script it, paste your query into the Python or JavaScript example above and run it against the Sorsa Search Tweets endpoint with your API key. The quickstart guide walks through key creation if you have not done that yet.

If you are coming from the official X API v2 and want a head-by-head migration walkthrough, the migration guide is the next step. Pricing details are on the pricing page.