Submit latitude/longitude pairs and get each one back as a row - the closest human-readable address, split into street, city, county, state and postcode, with a Plus Code and an IANA time zone alongside. Nineteen columns in the current shape, measured from real exports.
This is the one thing about reverse geocoding that surprises people, and it showed up plainly in our own exports.
Reverse geocoding does not look up “the address of this point”. It finds the nearest mapped object and reports that object's address. Usually the nearest object is a building and the answer is what you expected. Sometimes it is not.
One of our two test coordinates - 40.7449819,-74.0271321 in Hoboken - came back as 1, Hudson Street, Uptown, Hoboken, Hudson County, New Jersey, 07030, United States, with type set to bench and class to amenity. The pin was closest to a park bench, so the row describes a bench. The address is not wrong, but it is the address of a bench, and nothing in the address columns alone would tell you that.
That is why class and type matter more here than on the forward-geocoding side, and why they are the first columns to read after the address. Our other coordinate resolved to class place and type house - a real building. Filter on those two fields when the distinction matters to you, and treat the result as “what is nearest” rather than “what is at”.
A latitude/longitude pair is the entire input. There are no filters to configure.
class and type first.Both separators the reference documents work - a comma as in 37.427074,-122.1439166, or a space as in 40.7624284 -73.973794.
Measured from 5 real exports covering 8 rows and 2 distinct coordinates. Names are copied byte-for-byte from the header row, in sheet order. Example values below are real cells from those runs.
37.427074,-122.1439166. Present on every row of every run.37.427074. Echoes your input rather than snapping to the matched object.-122.1439166.321, South California Avenue, Evergreen Park, Palo Alto, Santa Clara County, California, 94306, United States.house on one of our rows - and bench on the other. Read this before you trust the address.place and amenity respectively. class and type are a pair.node on both of our rows.1734450110.Palo Alto, Hoboken. Wide shape only.US. Note this service returns a code where Geocoding returns a full country name.Santa Clara County, Hudson County.street_view.849VCVG4+RC, 87G7PXVF+X4. A short grid reference that works without a street network.94306, 07030.California, New Jersey.321 South California Avenue, 1 Hudson Street.America/Los_Angeles, America/New_York. Directly usable for local-time maths.lat.lon.Every column above carried a real value in the runs we hold. The sample is small and deliberately not expressed as a percentage - 8 rows across 2 coordinates tells you the shape of an export reliably and tells you nothing about behaviour at volume. The single most useful habit this table can give you: read class and type before you read the address, because they are what distinguishes a building from a bench.
Each of these came out of reading the exports rather than the reference, which is why they are worth the space.
Our Hoboken pin returned a complete, well-formed street address whose type was bench. Reverse geocoding answers “what is nearest”, not “what is at this point”, and street furniture is mapped too. If you are matching pins to premises, filter on class and type - or you will silently record a bench as a business address.
lat, lon, latitude and longitude all arrive as JSON numbers in every row we hold. On Geocoding the same four fields arrive as strings. If you share one parser between the two services, that difference will bite exactly once, in production, on a sort.
The older shape returns eight columns - query, lat, lon, address, type, class, osm_type and osm_id. The current one returns those plus eleven more, the same eleven the reference enumerates. Code against the eight and treat the rest as present-if-present rather than assuming a fixed header.
This one returns photo and country_code; Geocoding returns street_view and country. The Street View URLs follow the same pattern and the country fields hold different things - a two-letter code here, a full name there. If you normalise both into one table, map the names explicitly rather than trusting them to line up.
Anywhere your data arrives as coordinates and has to be read by a human - or joined to something that has an address.
Vehicle trackers, delivery apps and mobile forms all record coordinates. Running them through here turns a column of decimals into street, city and postcode, so a route report can be read without a map open beside it - and so stops can be grouped by area.
Photos, inspection records, sensor readings and incident reports often carry a lat/long and nothing else. One pass gives each of them an address, a county and a time zone, which is usually what turns a raw log into something a reporting tool can group.
When a record holds both an address and a coordinate, reverse geocoding the coordinate and comparing the two catches transposed digits and mis-typed postcodes. Read class and type when you do it, so a nearby bench does not look like a mismatch.
No subscription, no minimum, no per-seat licence. Your first 500 rows are on us - after that, pay-as-you-go.
Every new account, one-time. No credit card required. Worth spending some on coordinates whose answers you already know, so you can see how often the nearest mapped object is the one you meant.
Roughly $2 per 1,000 coordinates, one row per coordinate - exact to budget, because a coordinate that resolves to nothing still returns exactly one row.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams reverse-geocoding a live feed on a schedule. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.One turns addresses into coordinates; the other tells you which businesses sit at them.
The same service pointed the other way - addresses in, coordinates out, with the address parsed into country, state, city, street and postcode. Note its coordinates arrive as strings rather than numbers.
When the answer you actually want is the business rather than the address - categories, ratings, hours and contact details for what is at a location, not just what is nearest to it.
One of the lighter questions in the catalogue, and it is worth saying why rather than simply asserting it.
A coordinate, the address nearest to it and its time zone are facts about a location. Nothing in these nineteen columns describes a person: there is no name, no occupant, no contact detail. The underlying geography comes from OpenStreetMap, a public collaborative map, which is why the export carries OSM's own object ids and tags.
The thing worth thinking about is your input, and it deserves slightly more care here than on the forward service. A list of coordinates from phones, vehicles or wearables is a record of where people or their assets were - that is personal data in most jurisdictions before it ever reaches us, and resolving it to street addresses makes it more legible, not less sensitive. Hold it to the same standard you would hold the tracking data it came from. If you need to know who is at an address, that is a different and far more restricted category, covered by Whitepages Addresses with its own permitted-use rules.
On our side: publicly available sources only, nothing behind a login, no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
query, address, city, country_code, county, photo, plus_code, postal_code, state, street and time_zone - and the export adds eight more: lat, lon, type, class, osm_type, osm_id, latitude and longitude. Every one carried a real value in the runs behind this page.type was bench and class was amenity. The address is real; it just belongs to street furniture rather than a building. Read class and type before you treat a row as a premises address.37.427074,-122.1439166, or a space, as in 40.7624284 -73.973794. The pair you send is echoed back in query, and lat/lon carry your input rather than snapping to the matched object.lat, lon, latitude and longitude all arrive as JSON numbers. That differs from Geocoding, where the same four fields arrive as strings. If you share one parser across both services, handle that explicitly.849VCVG4+RC that identifies a small area without needing a street network. It is useful for places that have no conventional address, and it is stable enough to use as a coarse key.Paste your latitude/longitude pairs and get the nearest address, its parts, a Plus Code and a time zone for each. Your first 500 rows are free - enough to see how often the nearest mapped object is the one you meant.
Reverse geocoding is the step that makes coordinate data readable. GPS trackers, mobile forms, photos and sensors all record latitude and longitude and nothing else; turning a column of decimals into a street, a city and a postcode is what lets that data be grouped, reported on and understood by someone without a map open beside them. This service does it in bulk: submit coordinate pairs - comma-separated or space-separated, both documented - and each comes back as a single row.
The current export carries nineteen columns. Eleven are published by the reference: the submitted query echoed back, the nearest address as one comma-separated string, city, two-letter country code, county, a ready-made Google Street View link, a Plus Code, postcode, state, street and an IANA time zone. The export adds eight more that the reference does not mention: a numeric lat/lon pair echoing your input, the OpenStreetMap class and type of the matched object, its OSM object type and id, and a duplicate latitude/longitude pair. Across five real exports covering eight rows, every one of the nineteen carried a real value.
The single most important thing to understand is what "nearest" means. Reverse geocoding does not report the address of your point; it finds the nearest mapped object and reports that object's address. Usually that object is a building. Sometimes it is not: one of the two coordinates behind this page, in Hoboken, returned a complete and well-formed street address whose type was bench and whose class was amenity. The pin was closest to a park bench, so the row describes a bench. Nothing in the address columns alone would reveal that, which is why class and type are the first fields to read after the address, and why anyone matching pins to premises should filter on them. Three further details matter to whoever writes the importer, all observed rather than assumed. Coordinates arrive here as JSON numbers, whereas the forward Geocoding service returns the same fields as strings - a difference that will surface exactly once, in production, on a sort. There are two export shapes, an older eight-column form and the current nineteen-column one, so code against the eight and treat the rest as optional. And the column names differ from the forward service in two places: this one returns photo and country_code where Geocoding returns street_view and country, the latter holding a full country name rather than a two-letter code.
On the legal side this is among the lighter services in the catalogue: a coordinate, its nearest address and its time zone are facts about a place, and none of the nineteen columns describes a person. The underlying geography comes from OpenStreetMap, a public collaborative map. The input deserves more thought than the output, though. A list of coordinates taken from phones, vehicles or wearables is a record of where people or their assets were - personal data in most jurisdictions before it reaches us - and resolving it to street addresses makes it more legible rather than less sensitive, so it should be held to the same standard as the tracking data it came from. Publicly available sources only, nothing behind a login, no third-party trackers on the data layer, and exports auto-delete after 30 days. Your first 500 rows are free and need no credit card.