State Plane zones, EPSG codes and the foot that moves your data

The State Plane Coordinate System was designed in the 1930s by the US Coast and Geodetic Survey with one number in mind: scale distortion no worse than one part in 10,000, taken at the time as the limit of practical surveying accuracy. One part in 10,000 is 10 cm per kilometre. Holding that figure is what forces the zones to be small - the limit caps a zone at roughly 160 miles, about 260 km, across, which is why Texas has five of them and California six.

Compare that with UTM, where the central meridian scale factor of 0.9996 shrinks distances by one part in 2500, or 40 cm per kilometre, on the central meridian itself - but the scale climbs back through unity toward the edge of a 6 degree strip, reaching roughly one part in 1000 near the equator. State Plane trades coverage for four times less distortion. That is the bargain, and why American engineering and cadastral work sits in State Plane rather than UTM.

The projection follows the shape of the zone. Zones that run east to west use a Lambert conformal conic with two standard parallels; zones that run north to south use a transverse Mercator; the Alaska panhandle uses an oblique Mercator because it runs diagonally. California zone 3, EPSG:2227, is Lambert with standard parallels at 38 degrees 26 minutes and 37 degrees 04 minutes - about 152 km apart - so the scale is slightly too small between them and slightly too large outside. Arizona Central, EPSG:2223, is transverse Mercator with a central meridian scale factor of 0.9999, which is that one-in-10,000 design limit written directly into the projection.

There are about 125 zones in the 1983 system: roughly 108 in the lower 48, ten in Alaska, five in Hawaii, and one each for Puerto Rico with the US Virgin Islands and for Guam. Published counts differ by one or two, so treat any exact figure with mild suspicion.

This is where most people go wrong, and the registry does not make it obvious. A single State Plane zone is not one EPSG code. It is a grid of them: the datum realisation on one axis, the linear unit on the other.

Take California zone 3. EPSG:26943 is the federal metric definition on NAD83. EPSG:2227 is the same zone in US survey feet, which is what California state law specifies. EPSG:3493 and EPSG:3494 are the metre and US survey foot versions on the NAD83(NSRS2007) realisation. EPSG:6419 and EPSG:6420 are the metre and US survey foot versions on NAD83(2011). Six codes, one zone, and nothing in a coordinate file says which produced the numbers.

The EPSG remarks on these codes say it out loud: state law defines the system in feet, the federal definition is metric, and the foot code exists to match the statute. Arizona Central, EPSG:2223, carries the same remark with the opposite unit - Arizona legislated the international foot, so its name ends in (ft) rather than (ftUS), and its federal metric twin is EPSG:26949. If you assume that an American State Plane code in feet means US survey feet, Arizona, Michigan, Montana, North Dakota, Oregon, South Carolina and now North Carolina will all catch you out.

The realisation axis matters separately. NAD83(1986), NAD83(NSRS2007) and NAD83(2011) are not the same frame, and the same monument carries different coordinates in each. The EPSG remarks on the original 1986-era codes put a usable threshold on it: for work needing accuracy better than 3 feet, move to the HARN or a later realisation. Below that tolerance the realisation is a detail. Above it, it is the error.

One international foot is exactly 0.3048 m. One US survey foot is exactly 1200/3937 m, which is about 0.3048006096 m. The survey foot is larger by 2 parts per million. That ratio is so small it reads as a rounding error, and it is not, because of where State Plane puts its origin.

California zone 3 has a false easting of 2,000,000 m. In US survey feet that is exactly 6,561,666.667 ft. In international feet the same 2,000,000 m is 6,561,679.79 ft. The gap is 13.12 ft, which is 4.0 m, and it is there before you measure anything. Real eastings in that zone run around 6.5 million feet, so a file written in ftUS and read as ft - or the reverse - puts every point about 4 m from where it belongs.

Texas Central, EPSG:2277, is worse, because its false northing is 3,000,000 m: exactly 9,842,500 US survey feet, and 9,842,519.69 international feet. Read the wrong definition and the whole site moves nearly 20 ft, about 6 m, north or south. Arizona Central is the mild case. Its false easting is 700,000 international feet, exactly 213,360 m, and the same mistake there costs 1.4 ft, about 43 cm, because the coordinate values are an order of magnitude smaller.

That comparison is the point. The error is 2 ppm of the coordinate value, not 2 ppm of your site. Two control points 100 m apart stay correct relative to each other to within 0.2 mm, so every internal check passes, every distance between your own points is right, and the entire dataset is displaced bodily by several metres against everything else in the world. It survives review for the same reason a vertical datum error does: nothing inside the data disagrees with anything else inside the data.

NIST and the National Geodetic Survey published the final determination in the Federal Register on 5 October 2020, at 85 FR 62698, after a comment period opened in October 2019. The last day on which the US survey foot should be used was 31 December 2022. From 1 January 2023 it is obsolete, and the international foot is the single US definition of the foot.

What that notice did not do is delete your data. The NGS was explicit that it will continue to support the US survey foot for the State Plane Coordinate Systems of 1983 and 1927, because those systems and the hundreds of thousands of plats and plans referencing them are not going to be re-surveyed. The deprecation applies to the modernised National Spatial Reference System, which will support the international foot only. The NGS also stated that the 2022 date was independent of any delay to the modernisation itself.

The practical position has two sides. Anything new should be in metres or international feet. Anything legacy is very likely in US survey feet and will stay that way, and your software must be told so explicitly rather than left to guess from the word 'feet' in a header. A 2023 federal tally counted 28 jurisdictions whose SPCS 83 legislation specifies the US survey foot against six specifying the international foot, with North Carolina since moving across by statute.

The replacement, SPCS2022, is part of the NSRS modernisation alongside the NATRF2022 reference frame. It is designed with substantially more zones than SPCS 83, including statewide layers for projects that cross zone boundaries and low-distortion projections for local work. The NGS notice of October 2024 put the modernisation in 2025 or 2026, and that schedule has slipped more than once, so check the NGS site rather than this page for the current date.

The foot error has a signature. Your survey lines up perfectly with itself and sits a consistent 13 ft - or 4 m, or 20 ft, depending on the zone - off the county parcel layer, the road centreline or the orthophoto. Distances between your own points are right. Bearings are right. Only the absolute position is wrong, in one direction, by the same amount everywhere.

The realisation error looks almost identical but smaller: a uniform shift of a few tenths of a metre up to a metre or so, with no unit mismatch to find. The datum error - treating NAD83 as though it were WGS 84 - looks the same again at 1 to 2 m across the lower 48, and is worked through on the WGS 84 versus NAD83 page. Three causes, one symptom, and they stack.

The diagnostic order that works: read the EPSG code name first and see whether it ends in (ftUS), (ft) or nothing at all. Then take the ratio of the observed offset to the coordinate magnitude. If it comes out near 2 parts per million, it is the foot. If the offset is roughly constant at a metre or two wherever you are in the zone, it is a datum or realisation problem instead. Only after both of those should you start suspecting the survey.

If your coordinates came off drone imagery rather than a total station, check what the images actually recorded before blaming the projection. The metadata viewer on this site reads EXIF and XMP from your own photos in the browser, including GPS position and RTK or PPK status, and exports the positions as CSV, KML or GeoJSON so you can drop them over the layer you are arguing with.

The coordinate converter here runs proj4 in your browser: nothing is uploaded, and the arithmetic happens on your machine. It carries about two dozen State Plane zones as curated definitions - the six California zones from EPSG:2225 to EPSG:2230, Arizona Central, Colorado North, both Florida zones, five Texas zones, both Washington zones, Kentucky Single Zone and others - and fetches further codes from the EPSG registry on demand.

Here is the limitation that decides whether to trust the answer. The NAD83 definitions in this registry carry a null transformation to WGS 84. Converting WGS 84 latitude and longitude to a State Plane easting and northing here therefore applies no datum shift at all, so the result is out by the present NAD83 to WGS 84 separation of roughly 1 to 2 m across the contiguous United States. The projection maths is exact; the datum step is not performed.

Nor can the browser apply the grid-based transformations that would fix it. NADCON 5.0, the NGS grids that move coordinates between NAD83 realisations, and NTv2 grids elsewhere are large binary files. The same constraint stops this site doing vertical datum work: proj4 cannot carry a height through a transformation either, which is why EPSG:4979 is handled as EPSG:4326, and why heights are dealt with on the ellipsoidal versus mean sea level page instead.

Use this converter where metre-level agreement is enough - sanity-checking a zone, confirming which foot a file is in, turning a State Plane pair into latitude and longitude, or converting within one datum, where no shift is needed at all. Where the tolerance is centimetres, in cadastral work, construction stakeout or anything tied to published control, use the NGS tooling that ships the grids. NCAT handles State Plane, UTM, latitude and longitude and USNG with NADCON 5.0 underneath, HTDP handles plate motion and epochs, and VDatum handles the vertical. Those are the authority, and this page is not pretending otherwise.

Find the zone from a coordinate you trust rather than from a state name. A site near a zone edge belongs to whichever zone the statute puts it in, not the nearer one. If all you have is a latitude and longitude, put it into the zone finder on this site first, then pick the State Plane zone covering that point.

Write the full EPSG code into the deliverable, realisation and unit included. 'California zone 3' is ambiguous across six codes. 'EPSG:2227, NAD83 / California zone 3 (ftUS)' is not, and it takes the same few seconds to type.

Do the unit check as arithmetic rather than as a label. Compare the easting against the false easting you expect for that zone, or convert a single known control point both ways and see which answer matches the published value. Two minutes of that at the start of a project costs less than finding a 4 m offset at handover.

And if the client's control is published on NAD83(2011) while your aircraft wrote WGS 84, that is a datum transformation, not a unit question. Decide which frame the deliverable is in before the flight, and put it in writing.