US Address Test Data for Checkout Forms: A Practical QA Checklist

A checkout form looks simple: street, city, state, ZIP. But it's often where bugs hide. ZIP codes lose their leading zero, apartment numbers vanish, and a state dropdown sends "California" when the API expects "CA". These bugs are cheap to catch in staging and expensive in production.

This guide explains how to build a small, reliable set of US address test data for checkout forms. It covers the cases that matter, what each one should prove, and how to make sample addresses without using a real customer's details.

Scope note: Everything here is about testing your own software in development or staging. Fictional addresses can't receive mail and won't pass real address or card verification (AVS). Don't use them to sign up for services, get past identity checks, or make payments.

Why you shouldn't test with real addresses

Many teams start by typing in their office address or copying a row from production. Both are bad habits:

• Privacy: Real customer addresses in test databases, screenshots, and bug tickets are personal data. Under most privacy policies, and laws like the CCPA, they shouldn't be there.
• Coverage: One real address only tests the happy path. It won't have a suite number, a leading-zero ZIP, or a long street name.
• Reproducibility: Shared fictional fixtures can be committed to your repo and used by everyone. Real data can't.

A generator like the USA Dizhi US address generator gives you fictional, US-formatted records with the usual fields (street, city, state abbreviation, ZIP, phone) in one click. Sensitive-looking numbers on the page are built to fail validation.

The anatomy of a US address (what your form must handle)

A domestic US address is written from most specific to least specific:

1601 Demo Road, Apt 4B
Portland, OR 97205
United States

Field	Typical form label	Store as	Notes
Address line 1	Street address	text	House number + street name + suffix
Address line 2	Apt, suite, unit	text, optional	APT, STE, UNIT, FL, RM, BLDG
City	City	text	Separate from state
State	State	2-letter code	Display full name, store OR
ZIP code	ZIP / Postal code	text	5 digits, or ZIP+4 97205-1234
Country	Country	ISO code US	Explicit on international forms

If you want a quick reference for how each region writes addresses, the USA Dizhi address format lab has a format summary at the top of each country page. These include the Canada and UK pages, which help when your checkout also ships abroad.

The core test matrix

You don't need hundreds of addresses. Ten to fifteen well-chosen fixtures will catch most bugs. Here's a starting matrix:

#	Case	Example input	Expected behavior
1	Baseline	1601 Demo Road, Portland, OR 97205	Accepted, saved, shown back unchanged
2	Line 2 empty	(no unit)	No "required" error on line 2
3	Line 2 filled	STE 200	Kept, not merged or dropped
4	Leading-zero ZIP	Boston, MA 02108	Stays 02108 in DB, CSV, JSON, emails
5	ZIP+4	97205-1234	Accepted or normalized, per your spec
6	Invalid ZIP	9720 / ABCDE	Clear inline error, other fields kept
7	State/ZIP mismatch	Austin, TX 02108	Flagged if you validate region
8	Long street	60+ characters	No silent truncation
9	Apostrophe / hyphen	O'Neil Ave, Winston-Salem	Saved without escaping bugs
10	DC & territories	Washington, DC / San Juan, PR	Present in dropdown if you ship there
11	Tax-free state	Oregon, Delaware, Montana	Tax line = $0 (if in scope)
12	Billing ≠ shipping	Two different records	Both stored, correct one used for tax

Address line 2: the most-dropped field

Line 2 holds secondary unit designators like APT 4B, STE 300, or UNIT 7. Typical bugs:

• Line 2 marked required, so most real users get blocked.
• The value is saved but left out of the order confirmation email or shipping label.
• Autocomplete fills line 1 and quietly clears line 2.

Test both the empty and filled states. Also check the autocomplete="address-line2" attribute so browser autofill works.

ZIP codes are strings, not numbers

This is the classic bug. ZIP codes in New England and New Jersey start with 0 (Boston 02108, Hartford 06103). If any layer treats the value as an integer, such as a numeric input, an INT column, or a spreadsheet import, 02108 turns into 2108.

Follow it through the whole pipeline:

1. Type 02108 into the form.
2. Check the database value.
3. Export to CSV and open it in a spreadsheet.
4. Check the API JSON ("zip": "02108", not 2108).
5. Check the confirmation email.

A safe client-side pattern is ^\d{5}(-\d{4})?$ on an <input type="text" inputmode="numeric">.

State codes and dropdowns

Store the two-letter USPS code (CA, NY, TX) and show the full name in the UI. Test that:

• The value sent to your tax or shipping API is the code, not the label.
• DC is included. Add PR, GU, VI and military codes (AA, AE, AP) if you ship there.
• Typing a letter in the dropdown jumps to the right state.

For state-specific fixtures, USA Dizhi has per-state pages. Examples include California, Texas and Oregon, a handy no-sales-tax case.

City, state and ZIP consistency

ZIP codes follow geography: the first digit roughly marks a region (0 = Northeast, 9 = West Coast). If your checkout checks region consistency, include at least one deliberate mismatch, such as a Texas city with a Massachusetts ZIP. Confirm it's flagged with a helpful message.

Know what "consistent" means here. A matching city/state/ZIP set passes format and region checks. It does not mean the street address exists. Only a real address verification service (USPS-based, CASS-certified) can confirm that, and fictional data is meant to fail that step.

Building your fixture set in 10 minutes

1. Generate a few base records. Open the US address generator and copy a few full addresses. Use the "generate by city" option for city fixtures, for example New York or Chicago.
2. Check the combination. Make sure the city, state, and ZIP you keep belong together for "valid" cases. Fix any that don't before saving them as baseline fixtures.
3. Make the edge cases by hand. Add the line 2, leading-zero, ZIP+4, long-string and apostrophe variants from the matrix above.
4. Commit them as a JSON or CSV fixture file with ZIPs quoted as strings.
5. Label each fixture with the behavior it's meant to prove, so failures are easy to read.

Example fixture:

{
  "case": "leading_zero_zip_with_unit",
  "line1": "1601 Demo Road",
  "line2": "STE 200",
  "city": "Boston",
  "state": "MA",
  "zip": "02108",
  "country": "US",
  "expect": "accepted; zip preserved as 02108"
}

Common mistakes to avoid

• Using test addresses outside test environments. Fictional addresses belong in staging and automated tests, not in real orders, sign-ups, or verification forms.
• Expecting AVS to pass. Payment-provider sandboxes publish their own test card and address values. Use those for payment-gateway tests, and use generated addresses for form and data-handling tests.
• Testing only one country. If you ship internationally, add a few non-US fixtures. Postal code rules differ a lot (UK postcodes contain letters, and Japan writes addresses largest-to-smallest). See the Japan address format page for an example.
• Forgetting accessibility. Each field needs a visible label, errors need to be linked to their field, and focus should move to the first error after a failed submit.

FAQ

Can I use a generated US address to receive packages?

No. Generated addresses are fictional and for testing only. They're not linked to a real mailbox, so nothing sent there will arrive.

Will these addresses pass address verification or card AVS checks?

They shouldn't, and that's intended. Use your payment provider's sandbox test values for gateway testing, and generated addresses for checking how your own form stores and displays data.

Should ZIP codes be stored as numbers or text?

Text. ZIP codes can start with zero (02108), and ZIP+4 includes a hyphen. Numeric storage silently corrupts both.

What goes in address line 2?

Secondary unit details like APT, STE (suite), UNIT, FL (floor) or RM (room), followed by the number. It should usually be optional.

Is it legal to use a fake address generator?

Generating fictional data to test your own software is a normal development practice. Using that data to deceive a business, dodge identity checks, or make payments is not. Keep it in test environments.

How many test addresses do I need?

Usually 10–15 well-chosen fixtures covering the matrix above. Add more only when you add a new rule, like a new shipping region or tax rule.

---

Need sample data now? Try the free USA Dizhi US address generator. No signup needed, it runs in your browser, and it's built for format learning and software testing.