US State Plane zone finder
Find the State Plane zone for a US location from its state and coordinates: 34.0522, -118.2437 in California falls in California V, FIPS zone 0405. Results in states with several zones are flagged as approximate. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- State
- CA
- Latitude
- 34.0522
- Longitude
- -118.2437
- Zone
- California V
- Fips zone
- 0405
- System
- SPCS83
- Datum family
- NAD83
The US State Plane zone finder identifies the likely State Plane Coordinate System zone for a location from its two-letter state abbreviation and approximate WGS84 latitude and longitude. It returns the conventional NAD83 zone name and four-digit FIPS zone code, making it useful when a dataset names a state but omits its projected coordinate reference system. Because some zone boundaries follow counties instead of simple parallels or meridians, multi-zone results are intentionally described as approximate and should be checked against the governing project specification before survey-grade work.
What a State Plane zone tells you
The State Plane Coordinate System is a collection of projected coordinate systems designed for accurate work within parts of the United States. A jurisdiction may have one statewide zone or several zones arranged north to south, east to west, or around islands and irregular regions. This finder reports the conventional SPCS83 zone name and its four-digit FIPS zone identifier.
That is often the missing clue needed to interpret engineering, parcel, transportation, or utility data. The FIPS zone is deliberately returned instead of a single EPSG code because one State Plane zone can have several CRS definitions: metres versus US survey feet, an original NAD83 definition versus a later realization, or agency-specific conventions. For example, a California location can select one of six current zones, while Connecticut uses one statewide zone.
The state is therefore not merely descriptive input; it narrows the relevant zone family before latitude and longitude are evaluated. The result helps you discover the intended coordinate system, but the final CRS must still match the datum realization and unit stated by the data owner. Treat the returned zone as an informed selection key, not as permission to relabel unknown coordinates without checking their metadata.
How the location is evaluated
Send a two-letter postal abbreviation in state, plus lat and lon as finite WGS84 decimal degrees. A single-zone state can then return a high-confidence statewide result. For a multi-zone state, the capability applies a documented deterministic regional rule based on latitude, longitude, or island position.
These rules are well suited to approximate locations and ordinary CRS discovery, but several official State Plane boundaries follow county lines or other legal divisions that cannot be represented perfectly by one coordinate threshold. For that reason, multi-zone output carries approximate confidence and a verification note. Locations near a boundary deserve special care: consult the project survey control, state transportation department specification, county metadata, or authoritative CRS registry.
Input coordinates remain unchanged in the response so callers can audit what was evaluated.
Using the result in GIS and data pipelines
Use the returned zone and FIPS code to narrow a CRS search, validate incoming metadata, or route a record to a projection configuration already approved by your organization. Do not feed geographic longitude and latitude directly into a State Plane easting and northing field; selecting a zone is only the first step, and an actual coordinate transformation must use a suitable geodetic library. Next determine the required unit, typically metres, international feet, or US survey feet, and the exact NAD83 realization required by the project.
Those choices matter because coordinates can differ even when the zone name appears identical. In automated ingestion, store the original state, latitude, longitude, returned FIPS zone, and confidence together so a reviewer can reproduce the decision. Consider flagging every approximate result near an internal zone boundary for manual review.
No network lookup, current date, or random choice can change the answer. This makes the capability useful for repeatable preflight checks, but authoritative survey and legal work must still defer to the CRS definition named by the responsible agency or contract.
What you can do with it
Recover missing parcel metadata
Use a parcel's state and approximate centroid to identify the likely FIPS zone before matching it to an approved projected CRS.
Route field observations
Assign GPS observations to likely regional State Plane configurations before a controlled transformation step.
Validate a GIS import
Compare a supplier's declared State Plane zone with the zone suggested by the dataset's state and geographic extent.
FAQ
Does the result include an EPSG code?
No. A zone can correspond to multiple EPSG CRSs because the datum realization and coordinate unit differ. The result provides the conventional zone name and FIPS zone code so you can select the correct approved CRS.
Why is a multi-zone result marked approximate?
Some official zone boundaries follow counties or other irregular administrative divisions. Approximate latitude and longitude can identify the likely region, but cannot always settle a point near those boundaries.
Which datum does the finder assume?
It identifies the SPCS83 zone family associated with NAD83. It does not choose among later NAD83 realizations, and it does not identify legacy NAD27 zones.
Can this convert latitude and longitude to State Plane coordinates?
No. It selects a likely zone only. Use a geodetic transformation library with the exact zone, datum realization, and unit to calculate easting and northing.
Why do I need to enter the state as well as the coordinates?
Because the state narrows the family of possible zones before the coordinates are checked. Some states, such as Connecticut, have a single statewide zone, while California has six current zones.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/geo/state-plane-zone \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"state":"CA","lat":34.0522,"lon":-118.2437}'const res = await fetch("https://api.kit.forhosting.com/geo/state-plane-zone", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"state": "CA",
"lat": 34.0522,
"lon": -118.2437
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/geo/state-plane-zone",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"state": "CA",
"lat": 34.0522,
"lon": -118.2437
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/geo/state-plane-zone", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"state":"CA","lat":34.0522,"lon":-118.2437}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"state":"CA","lat":34.0522,"lon":-118.2437}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/geo/state-plane-zone", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"state": "CA",
"lat": 34.0522,
"lon": -118.2437
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "geo.state_plane_zone",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
lat_min | 17 |
lat_max | 72 |
lon_min | -180 |
lon_max | -64 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
The calculation is deterministic, private, and available in the browser or by API.
How the location is evaluated
Invalid states, non-finite numbers, impossible ranges, and coordinates outside the named state's approximate extent return an invalid_input error rather than a plausible-looking guess.
Using the result in GIS and data pipelines
The API costs $0.002 per successful request, while the browser implementation runs the same pure deterministic logic locally.
Technical questions
What does the API cost?
A successful API request costs $0.002. The browser runner uses the same deterministic logic locally, and invalid input is not charged.