Location on X is a sentence someone typed about themselves, and I spent a long time treating it as a fact about where they are. That gap is why a city filter can look broken while it is working exactly as designed.
Type one spelling of a city into a follower list and you get back the followers who used that spelling. Not the followers who live there.
The fix is not a better tool. It is a better query.
Why does a city search return so few of your X followers?
Because the filter matches text, not a place. Circleboom filters your X follower list by the location string each account typed into their own profile, reading it through Enterprise-grade X API access, so a single spelling returns only the people who wrote the city that exact way.
→ Find Twitter followers in a city
How I find Twitter followers in a city, spelling by spelling
The workflow I settled on after the one-query version kept under-reporting.
Open the full follower table before you filter anything
- Open Circleboom Twitter Management. Your own follower base is the dataset every city query runs against.
- Open All My Followers, which sits inside Follower / Following Management and Analytics. Every other follower view is a pre-filtered slice of this one.
Run the city as a set of strings, not a single word
- Click Filter Options and type your first city string into the Filter by Location field. The table drops to the accounts whose profile location holds that text.
- Clear the location chip in the Active Filters bar and run the next spelling. Abbreviation, native-language form, metro suffix, well-known neighborhood. Each pass returns a different slice of the same city.
- Stack one more filter on top of the survivors so the segment means something. Engagement tier, follower count range, or a keyword in Find in Bio & Name all combine as AND conditions with the location string.
Keep the segment before it dissolves
- Select the rows and send them somewhere durable. Add to List builds a Twitter List you can watch, and Export writes the rows to CSV with a Location column on every account.
That order matters because each step protects the next one: the unfiltered table sets your sense of scale, several spellings stop one of them standing in for the city, and the export dates a segment that drifts on its own.
Quick recap:
- Authorize the profile whose followers you are reading.
- Open All My Followers, not a pre-built segment.
- Run each city spelling through Filter by Location separately.
- Narrow the survivors with a second filter, then export or list them.
What the location filter is actually matching
The Filter by Location field is a free-text input matched against a free-text field, and nothing in between validates either side.
X treats the profile location as an optional, public, self-authored line. Its own page on how to customize your X profile puts location beside the bio and the website. You type it, you save it, and nothing checks the format or the truth of it.
A query on this field is nothing like a map lookup. That is the point behind the search for Twitter users who list a particular city.
So Circleboom is not resolving where a follower is. Circleboom reads what each follower wrote in that box and returns every account whose string contains your text.
That read runs on the Enterprise API access Circleboom holds as an official X Enterprise Developer company. The data arrives complete, and your account stays inside X's rules while you work through it.
That distinction is the whole article. A city query is a claim search, not a location search.
Once you accept it, the filter stops looking unreliable and starts looking narrow. Widen the query and the result widens with it.
You can see which cities your Twitter followers sit in before deciding which strings are worth running.
Why one city has more than one spelling
Every city of any size gets written several ways by the people who live in it, and the filter treats each version as a separate string.
The variants worth running every time:
- The plain name, exactly as the map spells it.
- The abbreviation locals actually use, like NYC or LA or SF.
- The name plus a country or state tag, like Manchester UK or Austin TX.
- The native-language form, like Munchen beside Munich or Roma beside Rome.
- A famous neighborhood or borough people write instead of the city.
Five passes on five strings will beat one pass on the "correct" one every time.
The neighborhood case is the one people skip. Plenty of accounts in a large city never write the city at all. They write Brooklyn, or Shoreditch, or Mission District, because that is the part of the map they identify with, and a query on the parent city walks straight past them.
There is a quieter version of the same problem inside a single string. Filter by Location is a contains match, so a short string catches more than you asked for. "York" pulls in New York. Longer strings are safer, which is another reason to run several narrow queries rather than one broad one.
The same discipline sits behind finding Twitter accounts in your local town, region, or city, applied to an audience you already have.
Why the followers map will not hand you the same list
The Followers Map answers a different question, and mixing the two is how people end up with a number they cannot act on.
The map aggregates the resolvable location strings across your follower base and draws them as orange bubble markers with a percentage on each region, with a flat map and a 3D globe view. Its companion tab plots your audience as a pie of named time zones.
Neither view lists accounts, and neither one carries a follow, remove, or list action.
There is a second thing the map does that the filter does not. Followers whose location field is empty, or whose string cannot be resolved to a region, are dropped from the map entirely. The chart has no bucket for them at all.
The percentages you read are shares of your locatable audience, not your whole audience.
Screen recording: the regional view I check first to decide whether a city is worth filtering for at all.
https://www.youtube.com/watch?v=sxFiCCCoteQ
Read together, the two surfaces make sense. The map tells you a region carries enough weight to bother with. The filter gives you the named accounts inside it.
Pairing that geography with the most engaged time zones on Twitter turns both into a posting decision instead of a chart.
Is a self-typed city good enough to act on?
Yes, for anything where the self-description is the point, and no for anything that needs a verified address.
A profile that says Austin is telling you how that person wants to be found. For deciding which city deserves its own content, recruiting for a meetup, scouting a pop-up location, or judging whether a market has enough weight to staff, that claim is exactly the signal you want.
It is the person's own answer to where they belong.
It is a poor basis for any decision that has to survive an audit. The field carries no proof, no timestamp, and no format.
X does hold a separate country signal, but that one is inferred from aggregated IP addresses for the account's own settings, and it is never exposed as a filterable follower attribute.
So treat a city segment as a soft segment. Act on it the way you would act on a bio keyword: confident about intent, silent about coordinates. The same caution applies to a list built from the best way to view the location of Twitter followers.
What the filter cannot see, and what to do about it
Two populations are invisible to any city query, and both are larger than people expect.
The first is everyone who left the location field blank. No string, no match, no matter how many spellings you run.
The second is everyone who moved and never went back to edit a line they wrote years ago. Old strings survive relocations, and the filter reads them exactly as written.
The arithmetic gets uncomfortable quickly. Say 5,000 of your followers genuinely sit in one metro area, a third of them left the field empty, and another slice wrote a neighborhood instead of the city name.
A single-string query can plausibly return well under half the people you were looking for.
It will do so without an error message.
That is why I run the pass as several queries and reconcile the results rather than trusting one. Exporting each pass makes the reconciliation easy, since the CSV carries the raw Location string beside every account and duplicates collapse on username.
Neither gap is a reason to skip the exercise. A partial city list you built knowingly beats a full one you invented.
You can still map your Twitter followers by city and check whether the count you got is plausible against that region's share of your audience.
Where the city segment goes after you build it
A city list is only worth building if something happens to it, and three next moves cover most of the reasons people run the query.
Watching is the cheapest. A Twitter List built from the segment gives you a running feed of that city without changing a single relationship.
Following back is the one to pace. Circleboom processes 50 follow actions every 15 minutes, up to 400 per day, and picks up again the following day once the daily limit is reached.
Reporting is the one that justifies the work. A dated export of a city segment is the artifact you attach to a partnership pitch. Pair it with the best time to post on Twitter and a geographic claim becomes a scheduling one.
Prefer to start from discovery rather than your own audience? Search Twitter by Location runs the same string logic against accounts who do not follow you yet.
Run it on the spellings you already tested. Whatever variants worked on your followers will work on strangers, and reusing them saves you rebuilding the string list twice for one market.
What skipping the wide pass costs you
Skip the multi-string pass and you will keep building city segments that quietly exclude most of the city.
The cost is not an error. It is a decision made on a fraction of the data, presented to a client or a partner as if it were the whole picture.
Undercounting a metro area by half changes which market looks worth investing in, and nothing on the screen tells you it happened.
Run the query wide, reconcile the passes, and keep the export. Then you can locate your Twitter followers city by city and defend the number when someone asks where it came from.
Questions about city filters on X
Does the location filter search bios as well as the location field?
No. Filter by Location reads only the profile location field. If a follower mentions a city in their bio but leaves the location box empty, use Find in Bio & Name instead, which searches display name and bio text.
Can I combine two city spellings into one query?
Not in a single pass. Every active filter in the panel applies as an AND condition, so two location strings would ask for accounts containing both. Run each spelling on its own and merge the exports afterward.
Does exporting a city segment cost anything?
Export runs on the token system, and the remaining token count sits next to the Export button before you click it. Filter the segment down first so a pass on the wrong string does not spend a token on rows you will discard.
