PHPackages sterlingdesign/address-normalizer - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Parsing & Serialization](/categories/parsing) 4. / 5. sterlingdesign/address-normalizer ActiveLibrary[Parsing & Serialization](/categories/parsing) sterlingdesign/address-normalizer ================================= Classes used to parse and normalize physical and mailing addresses v1.0.4(7mo ago)02MITPHPPHP >=8.1 Since Oct 9Pushed 7mo agoCompare [ Source](https://github.com/sterlingdesign/address-normalizer)[ Packagist](https://packagist.org/packages/sterlingdesign/address-normalizer)[ RSS](/packages/sterlingdesign-address-normalizer/feed)WikiDiscussions main Synced 1mo ago READMEChangelog (1)Dependencies (1)Versions (6)Used By (0) sterlingdesign/address-normalizer ================================= [](#sterlingdesignaddress-normalizer) This is a library written in PHP that can be used to read physical and mailing addresses and normalize them. Motivation ---------- [](#motivation) It turns out that automating work with addresses can be somewhat complicated. By way of example, here is a list of addresses: - 70 South Street, Unit A, Fort Wayne, IN, 46809-0200 - 70 South St., Unit A, Ft Wayne, IN, 46809-0200 - 70 South St, Suite A, Fort Wayne, IN, 46809 - 70 S Street, Unit A, Fort Wayne, IN, 46809 - 70A S St, Ft Wayne, IN, 46809-0200 In reality, most people can look at these and understand that they are all the same physical location. However, let's say you have a list of 500,000 addresses, and you need to automate the comparison process. Not so easy, especially considering that the above example only illustrates a few of the most common variations in describing a physical address. The key to being able to compare addresses using software is to be able to re-write the address into some sort of standardized format: a process of normalization. Research and Theory ------------------- [](#research-and-theory) The topic has been well developed in the past by several organizations, notably the Postal Service. Obviously, the software they use to automate the process of machine reading and printing bar codes has been well funded over the years. When I first started looking at the problem, I expected to find some good guidance from USPS sources. There is definitely some good matterial on their portal, much of it geared towards providing guidance for consumers to write addresses that can be read. However, implementations of software seem to be mostly proprietary due to the fact that mailing and addressing services are a lucrative business for some. In order to implement any sort of normalization process, the best theory I came across was in an online posting From ``` During the course of my research, I’ve found that the most flexible generic format for address data is this: Street Number [Int] Street Number Suffix [VarChar] – A~Z 1/3 1/2 2/3 3/4 etc Street Name [VarChar] Street Type [VarChar] – Street, Road, Place etc. (I’ve found 262 unique street types in the English-speaking world so far… and still finding them) Street Direction [VarChar] – N, NE, E, SE, S, SW, W, NW Address Type [VarChar] – For example Apartment, Suite, Office, Floor, Building etc. Address Type Identifier [VarChar] – For instance the apartment number, suite, office or floor number or building identifier. Minor Municipality (Village/Hamlet) [VarChar] Major Municipality (Town/City) [VarChar] Governing District (Province, State, County) [VarChar] Postal Area (Postal Code/Zip/Postcode)[VarChar] Country [VarChar] ``` After doing my own testing and homework, there are is an additional component to the structure proposed by the above author. The article above seems to describe physical addresses only. We also need to deal with delivery addresses. So it seems there are 4 types of addresses: - PHYSICAL - As above - POBOX - The only acceptable format for this address line is "PO BOX ##" - RR - the address line must contain RR ## BOX ## (SECONDARY\_DESCRIPTOR SECONDARY\_ID)\* - MILITARY - These seem to be formatted in any old way with little consistency. The USPS has formatting requirements that are rarely adhered to. This Implementation ------------------- [](#this-implementation) Durring development and testing, most of the data was for US addresses. Many international addresses have characteristics, such as containing multiple minor municipalities, that are not fully handled. The current 1.x version I've made available here works 99% of the time for my needs. It could stand more work, especially with code clean-up and interface solidification. ### Health Score 32 — LowBetter than 72% of packages Maintenance64 Regular maintenance activity Popularity2 Limited adoption so far Community6 Small or concentrated contributor base Maturity48 Maturing project, gaining track record Bus Factor1 Top contributor holds 100% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~0 days Total 5 Last Release 220d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/9a675ba8f5631f71000ed660a717ca08e8986d96e44c3e5b377b991bbc07f569?d=identicon)[sterlingdesign](/maintainers/sterlingdesign) --- Top Contributors [![sterlingdesign](https://avatars.githubusercontent.com/u/16853763?v=4)](https://github.com/sterlingdesign "sterlingdesign (5 commits)") ### Embed Badge ![Health badge](/badges/sterlingdesign-address-normalizer/health.svg) ``` [![Health](https://phpackages.com/badges/sterlingdesign-address-normalizer/health.svg)](https://phpackages.com/packages/sterlingdesign-address-normalizer) ``` ### Alternatives [masterminds/html5 An HTML5 parser and serializer. 1.8k242.8M229](/packages/masterminds-html5)[sabberworm/php-css-parser Parser for CSS Files written in PHP 1.8k191.2M65](/packages/sabberworm-php-css-parser)[jms/metadata Class/method/property metadata management in PHP 1.8k152.8M88](/packages/jms-metadata)[jms/serializer-bundle Allows you to easily serialize, and deserialize data of any complexity 1.8k89.3M627](/packages/jms-serializer-bundle)[hassankhan/config Lightweight configuration file loader that supports PHP, INI, XML, JSON, and YAML files 97513.5M170](/packages/hassankhan-config)[meyfa/php-svg Read, edit, write, and render SVG files with PHP 54613.9M42](/packages/meyfa-php-svg) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)