Your Street Address Your City State Zip Code Company: Fill & Download for Free

Within the United States, a ZIP code represents a USPS delivery are for a given month. ZIP codes can change at any time as needed by the US Postal Service. Each ZIP code is serviced by a specific post office, which may not even be in the same city as the ZIP code. ZIP codes can span cities, counties and even states.The easiest way to understand a ZIP code is to think of it as an alias for a city+state (though that is not completely accurate).So, when you enter a mailing address, you are submitting a street address and a city+state or ZIP code (or both). Think of it like this:1402 West Center St Orem, UT - (street + city + state)1402 West Center St 84057 - (street + ZIP code)1402 West Center St Orem, UT 84057 - (street + city + state + ZIP code)The ZIP code is a redundancy check for the city+state.That was a long answer. A short answer is that you should be fine. Once it is into the mail stream it will be corrected. The hangup could be if the website owner doesn’t do good address validation. If they do it right, they will find it and correct it before shipping.[disclosure - I know all this stuff because I work at an address validation software company called smartystreets]

First, be aware that postal addresses have redundancy and self-verifiable information in them, e.g.Is there a street with that name, or something close to it, in the named city?Does the zip code (Postal Code) match the city and district/neighborhood?Does a person (addressee) with that name live within the area?In the U.S. Postal Service post office where I worked in 1981, sorting was handled somewhat automatically by region (I've seen pictures of those regional centers in Documentaries), but once mail was delivered to our small town post office, two levels of human sorters looked at every piece of mail and parcel:the route sorters who would figure out which postal route a given piece of mail should be directed to out of the big pile delivered to our post office by the regional center - they're looking at street names to figure out to which postman's route that mail should go, andthe postman who does delivery on a route sorts the mail for his route in route-order out of the undifferentiated piles handed him by the route sorters. [that was me] One becomes quite familiar with the names, streets, addresses and order of a route that one sees six days a week, for weeks on end. A postman also has to memorize who along his route is having their mail held at the post office (e.g. because they're elsewhere for some period of time), and the list of people who've moved and left forwarding addresses (ideally the route sorters handle this, but sometimes they miss). The postman's route sorting system that I was trained in hadn't fundamentally changed since Benjamin Franklin's time as the first U.S. Postmaster General, and likely has not changed much since.The point to this is that there are an awful lot of humans looking at addresses on mail to answer the question "where does this go next?" but they're also effectively checking and asking "how can this address make sense?" before they make a routing decision. The humans in the system make mistakes, but they can also correct mistaken addresses too, and do quite often. It's rather amazing how well it works.Odds are good that if the parcel makes it to your local post office (which it should, just from the city, state, and zip code), they'll figure out how to get it to you, even somewhat misaddressed. However, if it's lost elsewhere, you might have a problem - it turns on who or what is examining that address, and whether they (or it) can make sense of the address or not.Second, you have "some" tracking number - whose is it?if it's the originating postal service's system, you'll probably have to ask them if they've received a USPS tracking number for the parcel when they handed it off. Also remember that international parcels have to clear United States Customs Service.if it's a USPS tracking number, you can look it up online: USPS.com® - USPS Tracking™Failing those two options, I suggest calling USPS customer service, or going to your local post office to seek help from a postal clerk or the local postmaster.One story about how the automated routing systems can go badly wrong (and why Internet Protocol (IP) packets have a Time-To-Live (TTL) field in their header). Many parts of Portland, OR have street numbers with five digits (10,000s), and this is rather unfortunately the same number of digits in a zip code. A company there bought an item from Germany, and it was shipped via DHL Express for high priority, international overnight express service.Alas, the person at the purveyor from whom the item was bought stuck the five digit street number starting with 10,000 into the zip code field as well (honest mistake - what is a random German supposed to know about U.S. zip codes? Still, s/he should have been more careful). The rest of the address was fine: specified the correct number & street in Portland, OR, but it seems that DHL's automated routing just looked at the zip code ... uncritically. It didn't check the zip code against the city or state, it just routed.So when the package landed in Chicago (city) from Germany, it got automatically routed on a cargo plane to New York City whose zip codes begin in 10,000 (Portland's zip codes begin with 97,000). And the DHL people (humans) in NYC looked at the city, state & address, didn't correct the zip code, and put the package back on the next cargo plane to Chicago.The package spun around this loop for a week, back and forth between Chicago and NYC, before the addressee company called DHL and asked them where the heck their package was (the online tracking report made it clear the package was in a potentially infinite loop, but why didn't DHL notice this?). A DHL employee was tasked to "catch" the package as it passed through Chicago again, and did.And then that employee took this international, overnight priority package, and put it on a truck from Chicago to Portland. [idiots!]

In most applications, the best datatype for postal addresses is going to be one of two things:a simple text field, which contains the unprocessed mailing address, with embedded newlines; ora serialized encoded object (XML, JSON, whatever floats your boat) containing a description of a mailing address with tagged components.I realize a lot of people (including some writing other answers to this question) have recommended storing each component of the address as a separate field. This is, almost invariably, a bad idea in the long run. This is because there is no universal set of attributes that apply to all postal addresses. Not all addresses have a “house number” or a “street”. All US addresses have a state code (which may or may not reflect the place to which the mailpiece will ultimately be delivered) and a ZIP code, but Canadian addresses have provinces or territories and Canadian postal codes, which look quite a bit different from ZIP codes. The set of “mandatory attributes” for a postal address is pretty small—indeed, the only universally required component is “country”, which is normally omitted when actually used to mail something within that same country!Furthermore, how often do you have a need to “select all customers whose street address starts with ‘elk’”? This is rarely necessary and argues for simply storing the entire address as an opaque object in a single field instead of a composite spread over multiple fields.One of the other answers arguing for selecting by city or state. Allow me to point out that postal addresses do not reliably reflect the city or state of the recipient. My postal address city line is “Melrose Park, IL 60164”. But I don’t live in Melrose Park. I live in unincorporated Leyden Township. My mail is delivered by the Melrose Park post office, and so my postal city is Melrose Park, but I don’t live there. In my case you can tell this because of the ZIP (the 60164 zip code is for addresses that are served by post office in Melrose Park but not actually in the Village of Melrose Park; it’s also used for people who live in the City of Northlake, which is why you cannot predict the city line from the ZIP code alone for 60164), but that’s a specific fact about this particular ZIP code. If you want to be able to select by actual city, you’ll need to use additional tools to determine what jurisdiction(s) a particular address is in, but these require using the entire address.Even state is not guaranteed: ever heard of the strange cities “Apo, NY” and “Fpo, NY”? These addresses (which are no longer in use, but were common not that many years ago) are used for delivery of mail to members of the Armed Forces abroad. They used to appear to be in New York, California, or Florida; they now use the “fake” state codes of AA, AE, and AP (which many software programs do not support at all).If you try to bake all this complexity into your database schema, you’re anti-future-proofing your database design. Your business doesn’t sell stuff outside the US so you don’t need to worry about international addresses? Fine. Design your schema like that. I guarantee you that a week after you go live with that schema, you’ll be told that the company is expanding into Canada and you need to update your system to deal with that. D’oh. Now you have to revalidate everything that has anything to do with addresses. If you hadn’t baked all the specific limitations of US addresses into your schema, you’d just have to write a few modules to deal with the specifics of Canadian addresses and test just those, but no, you had to bake an easily-voided assumption into your design. That’s bad architecture. Now think about what this means for a customer that already has 75 million customer addresses in their database. How much downtime will they tolerate while your update code restructures the address table to reflect the schema change that your lack of foresight now requires of them?So, unless you’re actually writing an library to parse or validate postal addresses, my advice will be to store the address in a single column. If you are going to regularly need specific derived values out of those addresses (e.g. state, tax jurisdiction, or any other value derivable from address) that is expensive to compute or needs to be readily selected against, you should precompute and store those values as auxiliary columns in the address table. (That’s how the sales tax compliance system we used at my last job worked: whenever an address was updated, the tax compliance system was invoked to determine the tax jurisdictions for that address—which could require user interaction—and the result of that determination written into the address record as auxiliary data.) The only attribute field I would even consider separating out from the rest of the address is country—and even there you can run into an issue: new countries do get created from time to time (South Sudan, anyone?).