Key takeaways
- Choose each sample for a specific behavior rather than visual realism alone
- Include unit identifiers, leading-zero ZIP Codes, ZIP+4, and long lines
- Keep names, emails, and phone numbers visibly synthetic
- Do not treat a format example as a deliverable address or identity
Authorship and review
Read our editorial and review principles- Written by
- Random Address Generator Editorial Team
- Reviewed by
- US Address Data Review Team
- Latest substantive update
- Published a scenario-based set of synthetic US address examples for layout, validation, and regression testing.
A basic three-line US address example
Start with the smallest case that still exercises the normal line order: recipient, street delivery line, then city, state, and ZIP Code. Use it as the control case before adding apartments, alternate delivery types, or longer values.
The example should be obviously labeled in test data. A realistic name attached to an arbitrary private house is unnecessary and creates privacy risk.
Seven sample formats, seven different tests
Keep the purpose beside the fixture. That makes failures easier to diagnose and stops a later cleanup from deleting the only leading-zero or long-line case.
| Synthetic address block | Purpose |
|---|---|
| TEST USER 02 / 51B OAK AVE APT 4B / BOSTON MA 02108 | Letter in primary number, apartment, leading-zero ZIP |
| TEST USER 03 / 225 N HUMPHREYS BLVD STE 501 / MEMPHIS TN 38188-1001 | Directional, suite, ZIP+4 |
| TEST USER 04 / PO BOX 0417 / MADISON WI 53701-0417 | PO Box and leading zero in box identifier |
| TEST USER 05 / 17 W 42ND ST / NEW YORK NY 10036 | Directional and numbered street |
| TEST USER 06 / 804 MARTIN LUTHER KING JR BLVD / ATLANTA GA 30312 | Long multiword street |
| TEST USER 07 / 12-14 MARKET ST / PHILADELPHIA PA 19107 | Hyphenated primary number |
| TEST USER 08 / 600 PINE ST NW STE 210 / SEATTLE WA 98101 | Postdirectional and business suite |
Split a sample into fields before testing the API
A formatted block is useful for a label preview, but an API normally needs structured values. Keep the recipient, address lines, city, state, postal code, and country code distinct. This reveals whether the failure belongs to formatting, serialization, or the backend model.
Store postal codes as strings. Keep Address Line 2 nullable. If the output formatter moves a suite onto Line 1, the original structure should still be available for editing.
{
"name": "TEST USER 02",
"address_line1": "51B OAK AVE",
"address_line2": "APT 4B",
"city": "BOSTON",
"state": "MA",
"postal_code": "02108",
"country": "US"
}Add invalid samples on purpose
A valid-only fixture set cannot prove that error handling works. Add separate records with a four-digit ZIP Code, missing state, oversized street, unsupported characters for a legacy export, and a unit placed in the city field. Mark them invalid in the fixture metadata so no one mistakes an expected rejection for a broken test.
Do not invent a correction when the input is ambiguous. The product should request a correction or present an authorized service suggestion with the original value still visible.
- Blank required Address Line 1
- Four-digit or alphabetic US ZIP value
- Full state name where an API requires the two-letter code
- Apartment field exceeding the downstream label limit
- PO Box sent to a carrier service that requires a street address
Keep sample data recognizable and disposable
Use names such as TEST USER 02, emails on example.com, and a run identifier that makes cleanup possible. Public non-residential locations can support location-field checks, but they should not be combined with a real person's identity.
Generated samples do not prove deliverability. If the test is specifically about a carrier or postal validation response, use the provider's sandbox or addresses your organization is authorized to test.
Frequently asked questions
What is a sample US address format?
A common three-line example is a recipient, a street and optional unit line, then city, two-letter state abbreviation, and ZIP Code.
Can I use sample addresses for shipping?
No. These samples are for software and layout tests. Use a legitimate, authorized, delivery-verified address for real shipping.
Why include a ZIP Code that begins with zero?
It catches numeric storage and spreadsheet imports that silently turn a five-digit ZIP Code into a shorter number.
Should every sample look realistic?
It should have the right shape for the behavior under test, but the identity fields should remain clearly synthetic and easy to remove.