Twitter (X) advanced search operators: what still works in 2026

You do not need the full list to get value out of search. Eight operators handle the overwhelming majority of real searches, and they all type straight into the X search box — no special page required. If you read no further, learn these.

There is also a form for this. X keeps a visual builder at x.com/search-advanced that fills in the boxes for you — words, accounts, dates, and engagement thresholds. In practice the form is a strict subset of what the search box accepts: it covers the basics safely, but every operator below — media filters, Lists, language, thread IDs — is raw-box only. Learn to type the operators and the form becomes a fallback, not a ceiling. If you would rather assemble a query without memorizing the syntax, our free X search query builder stacks them visually and hands you a string to paste.

The operators below work in the X web search box — we live-tested the set in June 2026, with a couple (list:, $cashtag) that are documented and standard but were not part of our test run. Stack as many as you want in one query — they combine with an implicit AND, so a space between two operators means both must be true. One caveat worth stating plainly: X ships changes without notice, so treat this as confirmed-today, not guaranteed-forever. The dead ones in the next section are the safer bet to act on.

Two rules trip people up. OR must be uppercase — a lowercase or is treated as a literal word. Everything else is case-insensitive, so From:NASA and from:nasa return the same posts. And there is no general wildcard: mark* does not match "marketing." The closest thing is a * inside a quoted phrase, which reportedly stands in for one word.

from: and to: are the workhorses. from:account filter:replies reads everything an account has said in other people's threads — often more revealing than their own timeline.

The likes operator is min_faves:, not min_likes: — the old internal name survived the rebrand even though the button says "like." Pair a threshold with a date to pull the highest-performing posts on a topic from a single week.

The filter: family takes a leading minus to invert it. -filter:replies strips replies to leave original posts; -filter:retweets strips reposts. That single character is the difference between a clean feed and a wall of reposts.

Dates take YYYY-MM-DD. For finer control, since_time: and until_time: accept a Unix timestamp and — despite a hundred cheatsheets calling them API-only — work in the web search box too. So does conversation_id:<id>, which pulls every reply in one thread.

This is the part every cheatsheet gets wrong, because nobody re-tests an operator once they have published it. Each of these is still listed as working across the top search results, and each one returns nothing — or the wrong thing — when you actually run it.

The geo operators are the most-mourned. For years you could pull posts within a radius of a city, which made X a genuinely useful local-news and event tool. X stopped attaching location to posts, the backend went with it, and near:, within:, and geocode: now return an empty page. The honest workaround is a List of accounts you know are local, not an operator.

The tell that a guide is stale: if it lists filter:vine, source:tweetdeck as a live feature, or calls the old TweetDeck "free" — it was last tested before 2023 and you should not trust the rest of it either.

Here is the mistake that wastes the most time, and almost every popular guide makes it. There are two different search engines at X, and they do not speak the same language. The consumer search box you type into is one. The X API — the developer endpoint apps and scripts use — is the other. An operator that works in one often fails silently in the other, returning a clean, convincing, empty result.

The short version: the X web search box uses filter: for content and type (filter:media, filter:nativeretweets), while the X API uses is: and has: (is:retweet, has:media) — and the two are not interchangeable. Paste an API operator into the web box and it returns an empty result with no error.

The classic failure: you read a guide that lists has:media, is:retweet, and place_country:, you paste them into the search box, and you get nothing. Those are API operators. The search box wants filter:media, filter:nativeretweets, and a geo operator that no longer exists. Same intent, different vocabulary. Here is the translation for the jobs people actually do:

One more catch in the API column: its boolean filters cannot stand alone. You cannot search the API for is:verified by itself — it has to accompany a real search term. The web box has no such rule. Unless you are writing code against the API, ignore the third column entirely and use the operators in the reference above. If you are writing code, the operators differ by access tier, which X documents separately.

Operators are only worth learning for what they let you find. These are the searches that earn their keep — pulling buyers, complaints, and leads out of the firehose. Replace the bracketed parts and paste them into X search.

1. People shopping for what you sell. Buying intent shows up as a question. This catches it and filters out the noise of people answering with links.

2. People complaining about a competitor. Switch-intent surfaces here first — someone frustrated enough to post is someone open to an alternative.

3. Unlinked mentions of your brand. People name you without tagging you constantly. This finds the conversations your notifications never showed you.

4. Support requests aimed at you. The replies and posts that need an answer today, before they curdle into a public complaint.

5. The posts winning a topic this week. A threshold plus a date pulls the highest-performing posts on any subject — good for spotting what to reply to, or what is working in your niche.

Each of these is a one-time search you have to remember to run again tomorrow. That is the real limit of operators: a query is a snapshot, not a feed. The continuous version is a saved monitor — the same query, running on a schedule, surfacing new matches in an inbox you can reply from.

That is what we built ReplySocial's keyword monitoring to do, and the same operators above become your monitor definitions. The setup is in how to monitor brand mentions, and the competitor version in how to track competitors on X. One more reason to automate it: at scale, some of what these searches return is bots and spam — scoring reply authors with BotBlock keeps the queue readable, and you can spot-check any handle with the free bot checker.

If advanced search seems worse than you remember, you are not imagining it. Three real limits explain almost every "it stopped working" complaint.

You have to be signed in. X has gated search behind login since 2023, so in practice you need an account. Old links that once showed results to logged-out visitors now hit a login wall, and no operator gets around it.

Recency is limited on the Latest tab. The Latest tab is effectively a recent-window feed — it surfaces new posts, not the full archive — so pulling a date range from years ago returns a thin, incomplete set. The Top tab reaches back further for high-engagement posts, but unevenly. Deep historical search is what the paid API and archive tools exist for; the consumer box was never built for it.

An empty result usually means a dead or wrong operator. Before you conclude search is broken, check the query against the reference above. Nine times out of ten the culprit is a geo operator that no longer works, or an API operator pasted into the web box. Strip the suspect operator, confirm the base search returns posts, then add operators back one at a time. The math is simple: the broken piece is almost always the operator your old cheatsheet swore by. For a fuller monitoring stack across X, Reddit, and the open web, the social media monitoring guide covers what search alone cannot.