AddressLab · Guides
Test an Address Form with One Saved Record
First published: · Chrome · 2026-10-24
Keep one generated record fixed while testing copy, save, reload and export. Changing the sample between steps makes a changed value look like a storage defect. In this run, the generated postal code 03060 survived browser storage and both saved-record exports; refreshing the page restored a different default example in the current panel, while the saved record remained available.
This walkthrough is for developers checking an address data flow. It measures AddressLab’s local save/export behavior, not a customer checkout, database, carrier or tax calculation. The screenshots show the English tool; the sample is synthetic.
Generate once and record the reference
Open the state-filtered US generator, choose New Hampshire and select Generate address. This filter supplies a leading-zero postal example; it does not certify any tax treatment. The initial fixed example can be copied or exported, but Save becomes available only after generating a record.
Our generated full address was 9263 Canal St, Nashua, NH 03060, United States. Your next random generation will differ. Use the downloadable snapshot for an exact comparison, or record your own output before continuing.
| Field | Generated / saved / exported value |
|---|---|
street | 9263 Canal St |
city | Nashua |
region | New Hampshire (NH) |
postalCode | 03060 |
country | United States |
Save, reload, and export the saved row
- Copy the record and confirm the street, city, state and postal value match the visible output.
- Save once, refresh the page, then expand Saved. Select the saved row as the reference; the current panel may now show the fixed startup example.
- Use Export saved records for JSON and CSV. Exporting the current panel after refresh would compare a different record.
- Inspect JSON and parse CSV as text. Check field names as well as values; display labels and machine keys are not interchangeable.
We observed one saved row after reload. JSON retained postalCode as a string, and the CSV field contained 03060. A spreadsheet opening the same file may still infer a number; this run did not launch Excel.
Map fields before testing your own application
| Source key | Typical target | Acceptance check |
|---|---|---|
street | Address line 1 | Do not split a house number by assuming every country uses the same order. |
region | State selector | The default export contains New Hampshire (NH). Map it to the target option NH; an internal regionCode is not included in this export. |
postalCode | Postal text field | The leading zero remains in the request, stored value and response. |
country | Country selector | The export contains a display name. Map to the target API’s documented country identifier, such as US; do not assume a countryCode key is present. |
For HTML autocomplete, use the field purposes documented by WHATWG, such as address-line1, address-level2 and postal-code. Those tokens describe a field; they do not validate the address. When adapting this record to your staging form, keep the original snapshot beside the request and response.
Carry this record into a checkout regression
The former tax-free checkout guide is incorporated here because the important action is a controlled change in the data flow. Start with the fixed saved address, a fixed cart and a documented expected response from your configured tax/shipping service. Change one destination at a time and record the resulting request, response, displayed totals and saved draft.
- Check that changing the state also sends the intended city and ZIP, rather than an old ZIP left from the prior address.
- Check both “billing same as shipping” states; a stale billing address should not silently overwrite the shipping destination.
- Compare the reopened draft with the accepted input and the service result. Do not infer a zero tax amount from this generator’s state filter.
These are checks to run in your own staging environment. We did not execute a checkout, submit payment or call a tax engine in this walkthrough.
Locate the first point where the value changes
| First difference | Investigate next |
|---|---|
| Correct input, changed request | Input coercion and payload mapping. |
| Correct request, changed stored value | Database type, import schema and server normalization. |
| Correct saved row, different export | Current-row versus saved-row selection and export field mapping. |
| CSV text correct, spreadsheet value changed | Import the postal column as Text; do not repair the source blindly. |
Before filing a bug, attach the original row, exact reproduction steps, application version, request/response and exported file. Remove real customer data. For country-specific optional fields, continue with the international boundary matrix; for input acceptance, use the ZIP field cases.
Sources and test scope
AddressLab used AI assistance to organize this guide and checked it against the recorded browser operations and the primary references below. Tests ran on 24 October 2026 against a local production build in isolated Chrome. External advertising and analytics requests were blocked during functional QA. These observations do not prove address assignment, delivery, mailbox ownership or tax outcomes.