Twitter Search Operators: The Complete Reference Guide

Most advice about Twitter search operators starts with a dangerous assumption: if an operator appears in an old cheat sheet, it must still work. That assumption breaks creator workflows. X search syntax remains useful, but support varies by search surface, date range, and operator, while location commands such as near: and within: are now especially unreliable according to SocialRails' 2026 compatibility coverage.

This guide treats the syntax as a living system rather than a static list. It separates commands into practical categories, shows the exact strings I'd use for discovery and monitoring, and flags the difference between a query that returns results and a query that returns the results you intended.

Why Most Twitter Search Operator Guides Are Already Outdated

A command can look valid in a cheat sheet and still fail in production. X retains a dependable core of account, date, language, content, and engagement filters, but support varies by search surface. Location modifiers show the risk clearly. near: and within: are effectively dead because X no longer attaches place data to posts in the way those filters require. An old location query may return nothing or results that do not represent the intended area.

Web search and API search create a second compatibility problem. The X search box accepts richer free-text syntax than some API endpoints, and unsupported commands may be ignored instead of rejected. A successful results page therefore proves only that the query loaded, not that every filter ran.

Test the exact query on the surface where it will power your workflow. For creator research, that means checking whether a monitoring query preserves account, date, and engagement constraints before relying on its results.

The durable foundation still includes since:, until:, from:, to:, filter:, and min_ engagement thresholds. Broader archival access also differs from recent search, as outlined in TwitterAPI.io's advanced search guide. Treat this guide as a 2026 compatibility map, separating operators that remain useful from commands better kept as historical references.

Core Query Building Blocks You Need First

Before adding filters, build a query that expresses the conversation you want. X treats spaces as an implicit AND, so launch update searches for posts containing both terms. It isn't the same as "launch update", which searches for the exact phrase in that order. The X operator reference documents this space-based logic, exact phrases, exclusions, mentions, hashtags, and account scoping.

Boolean logic gives you broader intent without abandoning precision. bitcoin OR ethereum matches either term, but OR must be uppercase. Lowercase or can be treated as an ordinary word. Use parentheses when alternatives belong together, as in (AI OR "machine learning") hiring.

The minus sign removes noise. crypto -scam keeps posts containing crypto while excluding posts containing scam. You can exclude a phrase too, for example ("product launch" OR "feature release") -"giveaway".

Building Block	Syntax	Example Query
Keyword	`word word`	`launch update`
Exact phrase	`"multiple words"`	`"launch update"`
Boolean alternative	`OR`	`AI OR automation`
Exclusion	`-term` or `-"phrase"`	`crypto -scam`
Grouped logic	`( )`	`(AI OR robotics) hiring`

A useful before-and-after pattern is analytics dashboard, which can return broad product commentary, versus "analytics dashboard" -jobs -course filter:links. The second query says what the topic is, which distractions to remove, and what format to prioritize.

If you're new to the interface, the guide to searching for tweets on Twitter is a useful starting point. Once the basic query behaves correctly, add one operator at a time. That makes failures diagnosable instead of leaving you with an empty page and no idea which command caused it.

Date and Account Operators for Precision Targeting

Date filters turn the live stream into a bounded research set. since:YYYY-MM-DD is inclusive, while until:YYYY-MM-DD is exclusive. Therefore, since:2025-01-01 until:2025-03-01 includes posts from January and February, but not posts published on March 1. The strict ISO format matters, and the Tweet Binder reference on advanced Twitter search documents this date behavior as a foundational part of operator-based retrieval.

Use both boundaries when you need a reproducible range:

"product feedback" since:2025-01-01 until:2025-03-01

A single boundary can still be useful for an open-ended search, but pairing the two makes the intended window obvious and prevents accidental drift. For hour-level work, supported timestamp variants include since_time: and until_time: with Unix timestamps. On an API, time boundaries may instead be request parameters rather than free-text operators, so don't paste web syntax into an endpoint without checking its query language.

Account filters answer different questions:

from:username finds posts authored by that account.
to:username finds replies directed to that account.
@username finds mentions anywhere in the text, including posts by other users.
list:ID searches posts from accounts in a public X List where the surface supports it.

For a creator-monitoring query, combine account alternatives inside parentheses:

(from:naval OR from:paborama) since:2025-01-01 until:2025-03-01

For replies aimed at a creator during a launch period, use:

to:creatorname ("feature request" OR bug OR feedback) since:2025-01-01 until:2025-03-01

The distinction between from: and @ is easy to miss. from: analyzes a publisher's output. @ analyzes the conversation around that account. If you're measuring how audiences respond to a creator, the second is usually more useful.

Engagement and Content-Type Filters That Cut the Noise

Keyword matching tells you what people mentioned. Engagement filters help you decide which posts deserve attention first. The core commands are min_faves:, min_retweets:, and min_replies:. They work best as a qualification layer, not as a substitute for reading.

Operator	Syntax Example	What It Returns
`min_faves:`	`climate min_faves:50`	Posts meeting a minimum likes threshold
`min_retweets:`	`AI min_retweets:20`	Posts meeting a minimum repost threshold
`min_replies:`	`launch min_replies:10`	Posts meeting a minimum reply threshold
`filter:links`	`research filter:links`	Posts containing links
`filter:media`	`product filter:media`	Posts containing media
`filter:images`	`design filter:images`	Posts containing images
`filter:videos`	`tutorial filter:videos`	Posts containing video
`filter:replies`	`support filter:replies`	Replies
`-filter:replies`	`support -filter:replies`	Posts excluding replies
`-filter:retweets`	`brand -filter:retweets`	Results excluding retweet noise
`filter:verified`	`news filter:verified`	Results associated with verified accounts, subject to surface behavior
`filter:blue_verified`	`topic filter:blue_verified`	Results associated with blue-verified accounts, subject to surface behavior
`filter:quote`	`launch filter:quote`	Quote-post results where supported

A visual discovery query might look like:

climate min_faves:50 filter:images

That combination surfaces more prominent image posts without requiring you to inspect every keyword match. For link research, use filter:links, then add -filter:media if you want text posts containing external URLs rather than posts whose media attachment is itself the main result.

Content-type filters have quirks. filter:replies can hide useful parent-thread context, and quote-post counts aren't always parsed consistently across surfaces. filter:verified and filter:blue_verified also represent different account populations, so don't treat them as interchangeable credibility labels.

The practical sequence is simple: start with the topic, add a date range, apply one engagement floor, then choose the format. If the result set collapses, remove the strictest filter first rather than adding more synonyms.

Deprecated Operators and What Replaced Them in 2026

Some commands should no longer be treated as dependable parts of a creator workflow. The most important failures are geographic. near: and within: were designed to search around named places or within a radius, but recent 2026 coverage describes them as effectively dead because X no longer supplies the place data needed for consistent matching. geocode: is similarly unreliable for ordinary discovery, even when older guides present it as a precise latitude-and-radius solution.

Older command	What older guides promise	Practical 2026 reality	Safer direction
`near:`	Posts near a named city	Inconsistent or empty coverage	Search city names, venues, local accounts, or country/language signals
`within:`	Radius around a location	Not dependable for general searches	Use contextual keywords and external location analysis
`geocode:`	Coordinate-based radius	Sparse and unreliable coverage	Use supported API location fields where available
`source:`	Posts sent from a client	Surface-dependent behavior	Inspect metadata outside the free-text query
`lang:`	Complete language isolation	Coverage can vary	Test the language code and review results manually
`include:nativeretweets`	Add native retweets	Legacy behavior may not map cleanly	Use current retweet or repost fields on the target surface

The right replacement depends on the question. For time-bounded retrieval, use explicit since: and until: syntax on the web when supported, or the endpoint's own start and end parameters in an API. For local audience research, combine place names, venue names, local hashtags, account filters, and language instead of trusting a radius command.

Be cautious with claims that an operator has been universally removed. Web search, API search, and third-party tools can expose different capabilities. A command that fails on one surface may still be accepted elsewhere, but that doesn't make it reliable for production analysis.

Advanced Query Combinations for Real Workflows

The value of twitter search operators appears when several filters answer one operational question. A query should have a job, such as finding emerging visual conversations, monitoring a creator's amplification, or locating replies worth qualifying.

Detecting rising visual conversations

climate min_faves:20 since:2026-01-15 until:2026-01-22 filter:images -filter:replies

This query removes replies, sets an engagement floor, and focuses on image-led posts in a fixed window. It doesn't prove that a topic is rising. It gives you a cleaner set from which to compare authors, repeated language, linked stories, and subsequent replies.

Monitoring creator amplification

(from:creator OR to:creator) min_retweets:50

from: catches the creator's own posts, while to: catches replies directed at that account. The combination is useful when you want to see both what the creator publishes and which conversations attract visible amplification. Add since: and until: when you're reviewing a campaign rather than monitoring continuously.

Scanning a niche without mainstream noise

("indie game" OR gamedev) since:2026-01-15 until:2026-01-22 filter:links -news -celebrity

This is a discovery pattern, not a universal formula. Replace the exclusions with terms that dominate your niche but don't represent the audience you want. Keep the query readable, because a long exclusion list can hide the fact that the core phrase is too broad.

Watching replies to a competitor

to:competitor filter:replies min_replies:10

This surfaces replies directed at the competitor that have attracted conversation. It's useful for spotting objections, integration requests, and comparison language, but inspect the thread manually. A reply count is a prioritization signal, not evidence that the author is a qualified prospect.

For live monitoring workflows, the XBurst real-time Twitter monitoring guide provides useful context on combining terms, exclusions, date boundaries, reply filters, and language constraints. The critical discipline is to preserve the query's meaning when moving across surfaces. Web syntax may use since: and min_faves:, while an API may expect separate time parameters and may not apply engagement filters from the query string at all.

Creator Use Cases From Finding Replies to Tracking Trends

Creators get more value from search when they look for conversations with an unmet need, not just mentions of a topic. Start with question-led phrases:

("how do I" OR recommend OR "anyone know") "video editing" -filter:retweets

That query is still broad, so qualify it with a date window, language, or engagement floor once you understand the volume. The aim is to find posts where a useful answer can earn attention without forcing a pitch.

A practical discovery loop

Find low-supply questions. Search for tool requests, workflow problems, comparisons, and explicit recommendations.
Remove amplification noise. Use -filter:retweets, and decide whether replies belong in the first pass.
Inspect context. Read the author's recent activity, the parent post, and the existing answers.
Reply with the missing piece. Give a specific answer before mentioning a product, newsletter, service, or profile.
Save promising accounts. Add relevant authors to a watch list and revisit strong threads after they develop.

For creator monitoring, use several narrow searches instead of one enormous from: query. A useful pattern is:

from:creatorname ("AI tools" OR automation) -filter:replies since:2026-01-01 until:2026-02-01

Another can focus on audience response:

@creatorname ("love this" OR question OR "how does") filter:replies

The first studies the creator's own themes. The second studies how people respond around them. Those are different datasets and should inform different actions.

Finding early niche movement

Run the same phrase set repeatedly and record what changes. Look for new authors, repeated links, expanding vocabulary, and replies that move from curiosity to disagreement or implementation questions. Search results are snapshots, not live analytics, so confirm momentum manually or with a compliant monitoring tool.

During an active campaign, check more frequently. During quieter periods, a few intentional checks can be enough. Don't confuse a high-engagement post with a trend. A trend has repeated signals across authors and conversations, not just one successful publication.

Operator Behavior Across Search Surfaces and APIs

There is no single X syntax standard. The web search box, Advanced Search form, mobile clients, API endpoints, and third-party dashboards can parse the same query differently. The web interface often accepts combinations that the form does not expose. Mobile clients may normalize a pasted query, so validate important searches on x.com before treating a result as reliable.

Standard recent search covers a limited recent window. Broader historical retrieval may require advanced access or full-archive availability, and results can change with account state and the surface being used. Treat the living compatibility map in this article as a starting point, then test the exact operator in the system that will run it.

Search surface	How operators work	Key limitation
X web search box	Accepts a broad free-text operator set	Result tabs and access level affect visibility
Advanced Search form	Builds supported filters through fields	Exposes only a subset of available syntax
Mobile X client	May accept search strings	Query normalization can differ from web
Official API recent search	Uses API query syntax and request parameters	Recent coverage and supported operators differ
Full-archive API access	Designed for broader historical retrieval	Availability depends on entitlement
Third-party dashboard	May pass through or translate syntax	Vendor logic and sampling can change results

The API is a separate system, not a faster copy of the search box. For automation, record the endpoint, query string, time parameters, and returned metadata. If an operator appears to fail, run the same query on x.com, compare the time range and filters, then check whether the API supports that syntax rather than assuming the operator was deprecated.

Visibility investigations need controlled comparisons. The XBurst Twitter shadowban check guide provides a practical frame for testing missing results without treating one absent post as proof of an account-level issue. Test from different surfaces, keep the query unchanged, and document what each surface returns.

Quick Reference Table of Every Operator

Use this table as a copy-starting point, not as a guarantee that every command works on every surface.

Operator	Purpose	Example	Status
`from:`	Author	`from:creator`	Live
`to:`	Replies to account	`to:creator`	Live
`@`	Mentions	`@creator`	Live
`list:`	Public List members	`list:123 topic`	Surface-dependent
`since:`	Inclusive date boundary	`topic since:2026-01-01`	Live on supported web search
`until:`	Exclusive date boundary	`topic until:2026-02-01`	Live on supported web search
`since_time:`	Timestamp boundary	`topic since_time:UNIX`	Surface-dependent
`until_time:`	Timestamp boundary	`topic until_time:UNIX`	Surface-dependent
`min_faves:`	Minimum likes	`topic min_faves:50`	Live on supported web search
`min_retweets:`	Minimum reposts	`topic min_retweets:20`	Live on supported web search
`min_replies:`	Minimum replies	`topic min_replies:10`	Live on supported web search
`filter:links`	Posts with links	`topic filter:links`	Live
`filter:media`	Posts with media	`topic filter:media`	Live
`filter:images`	Posts with images	`topic filter:images`	Live
`filter:videos`	Posts with video	`topic filter:videos`	Live
`filter:replies`	Replies only	`topic filter:replies`	Live, imperfect
`-filter:replies`	Exclude replies	`topic -filter:replies`	Live
`-filter:retweets`	Exclude retweets	`topic -filter:retweets`	Live
`lang:`	Language	`topic lang:en`	Variable
`filter:verified`	Verification filter	`topic filter:verified`	Variable
`filter:blue_verified`	Blue verification filter	`topic filter:blue_verified`	Variable
`near:`	Named location	`topic near:London`	Deprecated
`within:`	Radius	`topic within:5km`	Deprecated
`geocode:`	Coordinate radius	`topic geocode:...`	Unreliable
`source:`	Posting client	`topic source:client`	Surface-dependent
`filter:quote`	Quote posts	`topic filter:quote`	Surface-dependent
`url:`	URL matching	`topic url:example.com`	Variable

Common Mistakes and How to Troubleshoot Failing Queries

Most failures come from a small set of syntax and compatibility mistakes.

Broken phrase matching: launch update searches both words, while "launch update" requires the exact phrase. Fix it by choosing deliberately between broad keywords and quoted wording.
Lowercase Boolean: ai or automation may treat or as text. Use ai OR automation.
Malformed account syntax: from: username inserts a space and breaks the filter. Use from:username.
Dead location commands: coffee near:London within:5km may return little or nothing. Replace it with local names, venue terms, accounts, or language clues.
Over-filtering: topic min_faves:500 min_retweets:200 min_replies:50 can eliminate useful posts. Remove thresholds one at a time until you identify the restrictive layer.
One-sided date testing: A range such as since:2026-01-01 until:2026-02-01 is easier to validate than an open-ended boundary. Confirm the date behavior before stacking other filters.

When a query fails, strip it to one keyword and add each operator separately. Check both the result count and whether the returned posts visibly satisfy the filter. A successful page load isn't proof of successful filtering.

Frequently Asked Questions About Twitter Search Operators

Do Twitter search operators still work in 2026?

The core set remains usable on supported search surfaces: keywords, exact phrases, account filters, dates, content types, and engagement thresholds. Treat near: and within: as unreliable rather than as location targeting you can build a workflow around. Test the complete query in the interface or endpoint that will handle the final research.

Is mobile search different from web search?

Yes, results can differ. Mobile clients may normalize pasted syntax, hide controls, or expose fewer filters than the web interface. For research that informs content or outreach, run the query on x.com and compare the returned posts before saving it as a repeatable search.

Does standard search limit historical access?

Official recent search is generally limited to a short recent window, while broader history depends on the search feature and access level available to you. Use explicit since: and until: boundaries, then confirm that the returned posts cover the period you intended. Do not assume a successful result means the archive is complete.

How do web operators map to the API?

They rarely map one-to-one. An API may accept separate time parameters while ignoring web-oriented engagement filters, or it may support only a subset of the interface syntax. Test a small query in both systems before turning it into automation, and document which filters affect the response.

What should I do when a query suddenly stops working?

Remove legacy modifiers and location filters first, then test the topic alone. Add account filters, dates, and engagement thresholds individually. Compare syntax, access permissions, indexing, and search surface behavior so you can identify the failing layer instead of rewriting the entire query.

XBurst can scan X for conversations, creators, and niche topics, then support on-brand reply workflows. Use XBurst to move from saved queries to timely engagement, and review each conversation manually before responding.