The X advanced search operators list: what the web box takes, what the API rejects

What is the full X advanced search operators list?

Two documented sets make up the X advanced search operators list: the fields X's help centre exposes through the advanced search form on x.com, and the operators X's developer docs define for the v2 search endpoints. The sets overlap on keywords, accounts and language, then split on dates, engagement thresholds and geography, because the web box kept the syntax of the retired standard v1.1 API while v2 got new operator names. Check which side of that split you are on before writing a character.

Job	Operator	What it matches	Web box	X API v2
Content	keyword	A tokenized word in the post body	Yes	Yes
Content	"exact phrase"	The words in that order	Yes	Yes
Content	#hashtag	The hashtag, exact match	Yes	Yes
Content	$cashtag	A ticker symbol	Unverified	Yes
Content	url:	A token inside the link or expanded link	Unverified	Yes
Content	lang:en	The language X classified the post as	Yes	Yes, conjunction required
Content	-term, OR, ( )	Exclude, alternate, group	Yes	Yes
Accounts	from:handle	Posts written by that account	Yes	Yes
Accounts	to:handle	Replies addressed to that account	Yes	Yes
Accounts	@handle	Posts mentioning that account	Yes	Yes
Accounts	list:id	Posts by members of a List	Unverified	Yes
Accounts	retweets_of:handle	Reposts of that account	No	Yes
Accounts	is:verified	Posts from a verified author	Unverified	Yes, conjunction required
Accounts	bio:, bio_name:	Text in the author's profile	No	Enterprise Powerstream only
Engagement	min_faves:25	At least 25 likes	Yes	Rejected with 400
Engagement	min_retweets:10	At least 10 reposts	Yes	Rejected with 400
Engagement	min_likes:25	At least 25 likes	No	Yes
Engagement	min_reposts:10	At least 10 reposts	No	Yes
Engagement	min_replies:3	At least 3 replies	Unverified	Yes
Dates	since:2026-08-01	Posts from that day onward	Yes	No, use start_time
Dates	until:2026-09-01	Posts before that day	Yes	No, use end_time
Dates	start_time, end_time	ISO 8601 bounds	No	Yes, request parameters
Dates	since_id, until_id	Post ID bounds	No	Yes, request parameters
Media	has:media, has:images, has:videos, has:links	An attachment or a link	Unverified	Yes, conjunction required
Media	has:hashtags, has:cashtags, has:mentions, has:geo	That entity present anywhere	Unverified	Yes, conjunction required
Media	is:retweet, is:reply, is:quote	Post type	Unverified	Yes, conjunction required
Media	-is:nullcast	Drops promoted-only posts	No	Yes, negation mandatory
Geo	near:"San Francisco, CA"	Posts tagged near a place	Yes	No
Geo	within:15mi	Radius, pairs with near:	Yes	No
Geo	place:seattle	A tagged place	No	Yes
Geo	place_country:US	An ISO country code	No	Yes
Geo	point_radius:[2.355128 48.861118 16km]	A circle around a coordinate	No	Yes
Geo	bounding_box:[-105.30 39.96 -105.17 40.09]	A rectangle of coordinates	No	Yes
Threads	conversation_id:1334987486343299072	Every post in one thread	No	Yes
Threads	in_reply_to_tweet_id:, quotes_of_tweet_id:, retweets_of_tweet_id:	Replies, quotes and reposts of one post	No	Yes
Threads	context:, entity:	X's own topic annotations	No	Yes, entity: on recent search only

Last verified: 8 September 2026

Sources: X Help Center, How to use advanced search, footer stamped 2026 X Corp, read 8 September 2026. X developer docs, Search Operators and Build a query, read 8 September 2026.

Which operators work in the free web search box without an API key?

Fourteen operators carry a Yes in the web column above because X's help centre confirms them, and every other web entry is an inference. That page documents the advanced search form fields, then links two prebuilt searches whose URLs spell the syntax out: New Years -Resolution lang:en near:"San Francisco, CA" within:15mi since:2013-12-30 until:2014-01-02 and #WorldCup lang:en near:"Brazil" within:15mi until:2014-07-31. Treat those two URLs as the web reference and test anything beyond them yourself.

X attaches one access condition. Its help centre states that advanced search "is available when you're logged in to X.com," so the web box is free of charge, not free of an account.

Which X operators only work through the API?

Threads, annotations and precise geography are API-only, because those operators address post IDs and coordinate geometry that the web form has no field for. conversation_id: pulls every reply in one thread, context: matches X's own topic annotations, and point_radius: takes a longitude, latitude and radius. Reach for the API when your question is about the shape of a conversation rather than the words inside it.

Query length is the API's real ceiling. X's docs cap a self-serve recent search query at 512 characters, full-archive at 1,024, and enterprise at 4,096, and the whole string counts. The arithmetic for a keyword list is one line:

Characters = (variants x average variant length) + (OR joins x 4) + (parentheses x 2)

Twenty product-name variants averaging 12 characters, joined by OR inside one group:

(20 x 12) + (19 x 4) + 2 = 240 + 76 + 2 = 318 characters

That leaves 512 minus 318 = 194 characters for lang:, -is:retweet and the rest on the self-serve recent search tier. Full-archive doubles the room to 1,024. Budget the filters first and spend what remains on variants, and read what the X API costs per tier and how its request quotas work before you commit to that route.

Where a 512-character recent search query goes

Variants (20 x 12 chars)240

OR joins (19 x 4)76

Parentheses2

Left for filters194

How do you set engagement thresholds on X search?

X uses different names for the same threshold on each surface, and X's own operator reference says so in a warning box: "The equivalent operators on X web search are named min_faves: and min_retweets:. Those names are not valid in the X API and will be rejected with a 400 error. Use min_likes: and min_reposts: instead." min_replies: keeps its name on both. Each takes a non-negative integer and works on recent and full-archive search alike.

Thresholds cut noise and cut buying intent at the same time. A person asking for a tool recommendation collects two likes, not two hundred, so min_faves:50 deletes exactly the posts worth replying to. Set thresholds high for competitor and crisis tracking, and set them to zero or omit them when you are hunting for intent.

How do you search an exact date range on X?

The web box takes since: and until: with YYYY-MM-DD dates, and the API takes neither. since:2026-08-01 until:2026-09-01 returns August in the web box; the same range in the API is the start_time and end_time request parameters in ISO 8601, with since_id and until_id as the post-ID equivalents. X's help centre confirms the web archive reaches back to the first public post in 2006, and the API splits that into recent search at 7 days for every developer and full-archive back to 2006 for paid tiers.

Ranges are half-open on the web box, so until:2026-09-01 stops before 1 September rather than including it. Add a day to your end date when a report needs the final day counted.

Which media and geo operators still work?

Every has: and is: operator is documented for the API and none of them for the web box, so the media column is where most guides go wrong. X's migration table maps the old standard v1.1 names to the new ones: filter:links became has:links, filter:media became has:media, filter:images and filter:twimg became has:images, and filter:retweets became is:retweet. The web box descends from that legacy family, which is why filter: syntax still circulates and why none of it appears in current X documentation.

X's docs also disagree with themselves on video. The Search Operators reference lists has:video_link for native X videos, while the Search Posts introduction and the migration table both list has:videos. Try has:videos first and fall back, because one of the two pages is stale and X does not say which.

Geography splits cleanly. near: plus within: belong to the web box, place:, place_country:, point_radius: and bounding_box: belong to the API, and neither pair works on the other side.

Three queries a marketer runs on X

Buying intent, web box, verified operators only:

("looking for" OR "recommend a" OR "alternative to" OR "switching from") (CRM OR "help desk" OR helpdesk) lang:en since:2026-08-25 -from:YourBrand

Competitor churn signals, web box, thresholds turned on so only posts with traction surface:

(@Competitor OR Competitor) (cancelled OR canceling OR "switching to") lang:en min_faves:5 since:2026-06-01 until:2026-09-01

The same intent hunt through the API, where the operator names all change:

("looking for" OR "any recommendations" OR "alternative to") ("project management" OR "task tracker") lang:en -is:retweet -is:nullcast -has:links min_likes:2

Order of operations decides what each one returns. X combines AND before OR, so apple OR iphone ipad evaluates as apple OR (iphone ipad), and the parentheses in all three queries above are load-bearing rather than decorative. Generic Boolean logic beyond that belongs to the rules behind AND, OR and NOT; this page stays on X-specific syntax.

Which operators could not be verified?

Ten operator families appear in X's documentation only as retired standard v1.1 names, which makes them unverified rather than working: the whole filter: family, source:, card_name:, card_domain:, include:antisocial, include:sensitive_content, filter:follows, filter:has_engagement, filter:trusted and the geocode request parameter. X's migration overview lists each one under a Standard column with the v2 column left blank, and the standard v1.1 endpoint no longer exists.

The web box never migrated to v2 naming, so it inherited that legacy family whole, and X publishes no list of what survived. Run each operator against a query you already know returns results and compare the counts. Anything that returns the unfiltered set is being ignored rather than applied.

RedReplier watches X alongside Reddit, Bluesky, Facebook and Hacker News in one place, ranks what it finds by buying intent, and explains with AI why each mention was flagged. Its X monitoring takes keywords and a website instead of a query string, and it exposes an API and an MCP server for Claude Code, Cursor and any standard MCP client. The practice this sits inside is social listening, and the build-versus-buy version of the question is running a social listening API yourself.

Frequently asked questions

Does X advanced search work without logging in?

No. X's help centre states that advanced search is available when you are logged in to X.com. The search costs nothing, but it needs an account, so a logged-out browser or an unauthenticated scraper gets no results from the web box.

Why does min_likes: fail in the web search box?

The web box and the API use different names for that threshold. X's operator reference says min_likes: and min_reposts: are the API names and min_faves: and min_retweets: are the web search names, and that the web names return a 400 error from the API. Swap the pair depending on which surface you are querying.

How far back does X search go?

Back to the first public post in 2006 on the web box, according to X's help centre. The API splits that archive: recent search covers the last 7 days for every developer, and full-archive search reaches 2006 for pay-per-use and enterprise customers.

Can I use near: and within: with the X API?

No. near: and within: are web box operators only. The API's equivalents are place:, place_country:, point_radius:[longitude latitude radius] and bounding_box:.

Is it has:videos or has:video_link?

X documents both. Its Search Operators page lists has:video_link for native X videos, while its Search Posts introduction and its v1-to-v2 migration table list has:videos. Test both against a query you know returns video posts and keep whichever one changes the result count.

Why does my query return fewer posts than I expect?

Conjunction-required operators are the usual cause. X's docs state that operators such as has:media, is:retweet and lang: cannot stand alone in a query, so they need at least one standalone operator such as a keyword or from: beside them. The second cause is precedence: AND binds tighter than OR, so add parentheses around every OR group.

Does the X API query limit count characters or tokens?

The X API counts characters, not tokens, and the whole query string counts against the limit, operators included. Self-serve recent search caps out at 512 characters, full-archive doubles that to 1,024, and enterprise gets 4,096. Budgeting conjunction-required operators like lang: and -is:retweet first leaves more characters for keyword variants.

Why does -is:nullcast need a minus sign in front of it?

is:nullcast alone is not a valid X API operator; the docs require the negation, -is:nullcast. Written that way it drops promoted-only posts and keeps organic ones in the results. There's no positive form that requests nullcast posts directly.

How can I check whether an unverified X operator like source: or filter:trusted still works?

Test it against a query you already know returns results, once with the operator and once without, then compare the counts. If the number doesn't change, X is ignoring the operator rather than applying it. That test matters because X publishes no list of which retired standard v1.1 operators survived the move to v2.

Why do older X search guides list operators that return nothing today?

Many guides copy the retired standard v1.1 names, including the whole filter: family, source: and card_name:, because those names used to work and most sites that list them never marked them deprecated. X's migration table maps only some of them to v2 names such as has:links or is:retweet and leaves the v2 column blank for the rest. Test any operator you're unsure about before building a query around it.