Submit a list of addresses and get each one back as a row - latitude and longitude, the address normalised to a full postal form, and country, state, city, street, postcode and time zone split into their own columns. Twenty columns in the current shape, every one of them measured from real exports.
That is rarer than it sounds in this catalogue, and it is the reason this page can talk about confirmed columns rather than declared ones.
The published reference documents the request side - addresses in, batched up to 1,000 per request - and, unusually, it also enumerates eleven response fields: query, latitude, longitude, country, state, city, borough, street, postal_code, time_zone and street_view.
We hold five real exports covering seven rows and two distinct queries. The current shape returns those eleven plus nine more the reference does not mention - address, lat, lon, matched_address, type, class, importance, osm_type and osm_id - twenty columns in total. An older run returned only those nine. So the two sources corroborate each other where they overlap, and the export is the wider of the two.
Every one of the twenty carried a real value on at least one row, which is why the data dictionary below describes what each contains rather than hedging. The two exceptions are honest ones: borough and street came back empty for Central Park, NY, because a park has no street number.
An address is the entire input. There are no filters to configure.
A full street address and a bare landmark both work - the reference's own examples are 321 California Ave, Palo Alto, CA 94306 and Central Park, NY, and both are in the exports behind this page.
Measured from 5 real exports covering 7 rows and 2 distinct queries. Names are copied byte-for-byte from the header row, in sheet order. Example values below are real cells from those runs.
37.4270819. Identical to latitude; see the note below.-122.1439887. Identical to longitude.321, South California Avenue, Evergreen Park, Palo Alto, Santa Clara County, California, 94306, United States.house for the street address, park for Central Park.place and leisure respectively. Read class and type as a pair.0.0001 for the house, 0.612 for Central Park.node for the house, way for the park.1734450110. Stable enough to join on.lat.lon.United States.California, New York.Palo Alto, New York.Evergreen Park. Empty for Central Park, which has no borough component.321 South California Avenue. Empty for Central Park, which has no street number.94306. Worth sanity-checking on large area features; see the note below.America/Los_Angeles, America/New_York. Directly usable for local-time maths.https://www.google.com/maps?q=&layer=c&cbll=37.4270819,-122.1439887.Every column above carried a real value in the runs we hold, which is why this table describes contents rather than hedging. Two cells were legitimately blank - borough and street on the park - and that is a property of the place, not a failure of the lookup. The sample is small and deliberately not expressed as a percentage: 7 rows across 2 queries tells you the shape of an export reliably and tells you nothing about hit rates at volume. Run a slice of your own file on the free tier first.
Each of these came out of reading the exports rather than the reference, which is why they are worth the space.
lat and latitude carry the same value, and so do lon and longitude - in every row we hold. Neither is more authoritative than the other; the older 9-column shape simply has only the short pair. Note that both are strings, not numbers, so cast before you do arithmetic or you will sort -122 next to -73 alphabetically.
Submitting Central Park, NY returns coordinates and a matched address, but borough and street come back empty, because there is no street number to give. If your pipeline treats a missing street as a failed lookup it will discard perfectly good rows. Branch on whether coordinates are present, not on whether every address part is.
The Central Park row came back with postal_code 11025. Central Park's postcodes are in the 100xx range, so that value does not describe the park. A big polygon gets its address parts from a representative point, and for features that span many postcodes the result can land outside. Trust the coordinates; verify the postcode before you route mail or join on it.
class and type are the key and value of the matched feature's main OSM tag, osm_type and osm_id point at the object itself, and importance is OSM's computed importance rank. That is genuinely useful: filtering on class lets you keep buildings and drop parks, and importance separates a landmark from a doorway - 0.612 against 0.0001 in our two rows.
Geocoding is plumbing - it is what has to work before the interesting analysis starts.
Every resolved row carries latitude and longitude, so a spreadsheet of customers becomes something you can plot, cluster and draw catchment areas around. One request takes up to 1,000 addresses, which makes a large file a handful of calls rather than a rate-limit problem.
The parsed columns do the work the coordinates alone cannot: state, city and postal_code arrive in their own fields, so assigning an account to a sales territory or a service area becomes a join rather than a string-parsing exercise.
time_zone comes back as an IANA name like America/Los_Angeles, which is exactly what a date library wants. That turns "what time is it for this customer" from a guess based on country into a correct answer that survives daylight saving.
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. Enough to run a real slice of your address file and see how it copes with the messy rows - the abbreviations, the missing postcodes, the landmarks.
Roughly $2 per 1,000 addresses, one row per address - exact to budget, because an address that resolves to nothing still returns exactly one row.
Volume pricing, SLAs, dedicated workers and bespoke onboarding for teams geocoding a large file on a schedule. Tell us your numbers and we'll quote.
LIVESCRAPER10 at checkout.One turns coordinates back into addresses; the other tells you which businesses sit at them.
The same service pointed the other way - coordinates in, a human-readable address out, with a Plus Code and county alongside. Useful when your data arrives as GPS pings rather than typed addresses.
Coordinates tell you where; this tells you what is there - the businesses at a location with their categories, ratings, hours and contact details. The natural next step once a list is on the map.
One of the lighter questions in the catalogue, and it is worth saying why rather than simply asserting it.
An address, its coordinates and its time zone are facts about a location. Nothing in these twenty 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 one thing worth thinking about is your input. If the addresses you submit are customer home addresses, then that list was personal data before it reached us and remains so afterwards - geocoding it adds precision to a record about a person. Handle the file accordingly. If you need to know who lives at an address rather than where it is, 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, latitude, longitude, country, state, city, borough, street, postal_code, time_zone and street_view - and the export adds nine more: address, lat, lon, matched_address, type, class, importance, osm_type and osm_id. Every one of the twenty carried a real value in the runs behind this page.address, lat, lon, matched_address, type, class, importance, osm_type and osm_id; the current one returns those plus the eleven the reference documents. Write your importer against the nine and treat the rest as present-if-present rather than assuming a fixed header.lon and longitude. The short pair appears in both export shapes and the long pair only in the wider one, so if you want a single code path, read lat and lon. Both arrive as strings, so cast them before doing arithmetic or sorting.Central Park, NY returns coordinates, a matched address, a city, a state and a time zone, but no street number and no borough - a park does not have them. Treat a row as successful when it has coordinates, not when every address part is filled.postal_code 11025, which is not a Central Park postcode - a big polygon takes its address parts from a representative point, and for a feature spanning many postcodes that point can land outside. The coordinates are the dependable part; verify the postcode before you route mail on it.Paste your addresses and get coordinates, parsed address parts and a time zone for each one. Your first 500 rows are free - enough to see how it handles the messy rows in your own data.
Geocoding is the step that has to work before any location analysis starts: a column of human-typed addresses becomes a pair of coordinates that can be plotted, measured and joined. This service does that in bulk. Submit a list of addresses - a full street address like 321 California Ave, Palo Alto, CA 94306, or a bare landmark like Central Park, NY, both of which are the published reference's own examples - and each comes back as a single row, so an input file and an output file line up exactly.
The current export carries twenty columns, and this page is unusual in the catalogue for being able to describe all of them from measurement rather than from a header alone. Eleven are published by the reference: the submitted query echoed back, latitude and longitude, country, state, city, borough, street, postal code, an IANA time zone, and a ready-made Google Street View link built from the coordinates. The export adds nine more that the reference does not mention: the address as submitted, a short lat/lon pair, a fully normalised comma-separated address, and five fields drawn straight from OpenStreetMap - the class and type of the matched feature's main tag, the object's OSM type and id, and OpenStreetMap's computed importance rank. Across five real exports covering seven rows, every one of the twenty carried a real value at least once.
Four details matter to whoever writes the importer, all of them observed rather than assumed. The coordinates arrive twice - lat and latitude are the same value, as are lon and longitude - and both are strings rather than numbers, so they need casting before arithmetic or sorting. A landmark is not an address: the Central Park row returned coordinates, a city and a time zone but no street and no borough, because a park has neither, so a pipeline should treat the presence of coordinates as success rather than requiring every address part. Postcodes deserve a sanity check on large features: that same park row returned a postal code outside the 100xx range that actually covers Central Park, which is what happens when a polygon spanning many postcodes reports the one at a representative point. And the OpenStreetMap fields are genuinely useful rather than decoration - filtering on class separates buildings from parks, and importance separates a landmark from a doorway, 0.612 against 0.0001 in our two rows.
On the legal side this is among the lightest services in the catalogue. An address, its coordinates and its time zone are facts about a place; none of the twenty columns describes a person, and the underlying geography comes from OpenStreetMap, a public collaborative map. The one thing worth thinking about is the input: if the addresses you submit are customers' home addresses, that list was personal data before it reached us and stays personal data afterwards, so it should be handled accordingly. 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.