How ATS Parses Location, Remote & Relocation

A recruiter filters candidates to "Remote — US only" or "Austin, TX / open to relocate." Your header says "Karachi | Open to opportunities." Depending on how Greenhouse, Workday, Lever, iCIMS or Taleo tokenizes that line, you either land in the shortlist or get screened out before a human reads a single bullet. Location is not free text to most ATS systems. It is a set of fields: city, state/region, country, and often separate flags for remote and relocation.

I build Smart Resume Analyzer, an ATS resume checker, and I have spent nine years as a Principal Software Engineer in Karachi writing search and matching code in PHP, Laravel and Node. I wrote this with help from AI tools and checked every command and claim myself. This piece covers how location strings get parsed, what "Remote" and "open to relocate" actually do in common systems, and how to rewrite your contact header so both the parser and the recruiter see the same intent.

How does ATS parse location, remote and relocation?

Direct answer: Most ATS parsers pull a city, state/region and country from your contact header into structured fields, then store "Remote", hybrid and "open to relocate" as separate preference flags or free-text notes. Write a plain city–state–country line, put remote or relocation preferences in clear words next to it, and avoid graphics, tables or multi-city laundry lists that confuse field extraction.

What the contact header actually becomes

After upload, your resume is not one blob of text. The parser tries to fill a candidate profile. Location usually lands in three places:

Destination	Typical source on the resume	What breaks it
City / locality field	First place-looking token near the top	Two cities on one line; "Greater X Area"
State / region field	Abbreviation or full name after the city	Non-US formats without a country
Country field	Explicit country, or inferred from state	Missing country when applying internationally
Work authorization / preferences	Separate form questions or notes	Putting only "Remote" with no city at all
Recruiter keyword search	Raw resume text still indexed	Fancy unicode dashes, icons, multi-column headers

The structured fields power filters ("show me candidates in Texas"). The raw text still powers keyword search ("open to relocate"). You need both to be correct.

Location follows the same rule as how ATS parses your resume contact header: plain text near the top, one idea per line, no icons.

How Greenhouse, Workday, Lever, iCIMS and Taleo treat location

Vendors differ, and each employer's configuration differs more. Treat this as a safe operating assumption, not a claim about one customer's setup.

ATS	How location usually lands	Remote / relocate	Safe assumption for your resume
Greenhouse	Parsed into candidate location; recruiters filter and boolean-search	Often a separate preference or custom field	Plain "City, ST, Country" plus a clear remote/relocate sentence
Lever	Profile location plus resume text search	Tags and notes are common	Same; keep preferences in readable text
Workday	Strong structured profile fields; location hierarchies	Relocation and remote often collected on the application	Fill profile fields carefully; mirror them on the resume
iCIMS	Profile fields and resume keyword search	Preferences frequently live on the application form	Do not rely on the resume alone for "open to relocate"
Taleo	Parsed fields vary heavily by Oracle/Taleo config	Screening questions often own remote/relocate	Answer questions and keep the resume consistent

These products extract tokens and fill fields; they do not "understand" clever one-liners. Graphic banners and two-column headers with location on the right drop extraction quality—the same failure mode as hidden characters that break ATS keyword matching.

Tokenization: what "Remote — US" becomes

A simplified tokenizer lowercases text and splits on anything that is not a letter or digit:

import re def tokens(s): return re.findall(r"[a-z0-9]+", s.lower()) samples = [ "Austin, TX | Open to relocate", "Remote — United States", "Karachi, Pakistan · Hybrid OK", "📍 SF Bay Area / Open to remote", ] for s in samples: print(s, "->", tokens(s))

Typical output:

Austin, TX | Open to relocate -> ['austin', 'tx', 'open', 'to', 'relocate'] Remote — United States -> ['remote', 'united', 'states'] Karachi, Pakistan · Hybrid OK -> ['karachi', 'pakistan', 'hybrid', 'ok'] 📍 SF Bay Area / Open to remote -> ['sf', 'bay', 'area', 'open', 'to', 'remote']

Emoji and fancy dashes become separators or vanish. "SF Bay Area" is not "San Francisco, CA" unless the employer added a metro synonym. "United States" and "US" are different tokens—mirror the job post and include the other form once if you have room.

Weak vs ATS-optimized contact headers

Weak	ATS-optimized	Why
`📍 SF \	Worldwide remote`	`San Francisco, CA, United States` plus `Remote (US time zones); open to relocate within the US`
`Based in Karachi, open to anything`	`Karachi, Pakistan` plus `Open to remote roles; open to relocate for the right role`	"Anything" is not a filter value
`NYC / London / Dubai`	Pick the primary base city, then state remote or relocate separately	Multi-city lines often fill the city field with garbage
`Willing to travel extensively`	`Open to travel up to 25%; based in Austin, TX, United States`	Travel ≠ relocate; keep them distinct
Location only in a footer or sidebar	Location in the top contact block under your name	Parsers weight the header; footers get skimmed or missed
`Hybrid` alone	`Austin, TX, United States — hybrid (3 days onsite)`	Hybrid needs a city; alone it is ambiguous
Country missing on international apps	Always include country: `Berlin, Germany`	State-only formats fail outside the US

A few extra words; not stuffing—just field-friendly.

AI-generated image.

Remote, hybrid and "open to relocate" as separate signals

Recruiters filter three axes separately: where you live now, work arrangement (remote / hybrid / onsite), and relocation willingness. Collapsing them into "Remote / Open" hurts you. A US employer filtering "Austin metro + open to relocate" will miss a header that only says "Remote." Remote companies may still need your city for tax reasons. Put the city first, then preferences.

When a job post says "Remote — US only," mirror that language:

Austin, TX, United States Remote (US); not seeking relocation

When it says "Onsite in Denver; relocation assistance available":

Karachi, Pakistan Open to relocate to Denver, CO, United States

Keep the application form consistent. A No on "willing to relocate?" with Yes on the resume is a trust problem.

Keep location in the contact header

Do not invent a "Geography" or "Base of Operations" section. Put city and preferences under your name, using headings parsers already recognize—see resume section headings ATS parsers recognize.

Diagnostic checklist: location in 10 minutes

Paste the top six lines into a plain-text editor. Fix icons, columns or broken line breaks at the source.
Confirm one primary city, region and country. Expand metro nicknames to a real city.
State remote / hybrid / onsite in the job post's words.
State relocation separately, with geography if you have it.
Drop multi-city wish lists from the header.
Strip emoji and decorative separators.
Align resume answers with the application form.
Search the PDF for city, remote, relocate and the country token the posting uses.
Re-parse with an ATS-style checker such as my ATS parser online.
Match LinkedIn open-to-work location settings to the resume.

Pre-submit checklist

[ ] Top of resume shows City, Region, Country in plain text
[ ] Remote / hybrid / onsite stated in words the job uses
[ ] Relocation stated separately, with geography if known
[ ] No emoji, text boxes or multi-column location blocks
[ ] No contradictory answers between resume and application form
[ ] Country included on every international application
[ ] Metro nicknames expanded at least once
[ ] LinkedIn location preferences match the resume story

Frequently asked questions

Should I put "Remote" instead of my real city?

No. Keep the real city and country, then add remote preference on the next phrase or line. Many employers still need a taxable location, and city filters will skip a resume that only says Remote.

Does "open to relocate" help for fully remote jobs?

Usually it is neutral. Remote-only teams care about time zone and work authorization more than relocation. Say you are remote-first, and only emphasize relocation when the posting mentions onsite or hybrid hubs.

How do I handle multiple citizenships or work authorizations?

Do not overload the location line. Put authorization in a short separate line or in the application form: "Authorized to work in the US and EU." Location stays geographic.

Will ATS reject me if my city is outside the job's country?

Filters might exclude you before a human sees the file. If you are seriously open to relocating or working remote across borders, say so explicitly and make sure the application questions reflect that. The resume alone rarely overrides a hard location filter.

Are state abbreviations safer than full names?

For US roles, TX and Texas both appear in postings. Including the city plus abbreviation plus country covers most searches: Austin, TX, United States. For non-US roles, prefer the local region name the employer uses.

Can I list a future relocation city before I move?

Only if you will actually be there on the timeline you claim. Misleading location is a trust problem in interviews. Better: keep current city and write "Relocating to Denver, CO in March 2027; available remotely until then."