You open a new constituent record from an online membership purchase and the ZIP code reads jane@example.com. The address is otherwise fine. Nobody typed that on purpose. The browser’s autofill did it, and the web form accepted it.
This one is frustrating because the cause sits between two things you don’t fully control: how the visitor’s browser guesses which saved value goes where, and how the form fields are marked up. Below is what’s actually going on, what you can and can’t change, and how to keep the bad data out of Altru.
Why a browser puts an email address in a ZIP field
Chrome, Safari, Edge, and Firefox don’t read a form the way a person does. When someone clicks into a field and picks a saved profile, the browser fills the whole form at once by guessing what each field is for. It uses clues in the page code:
- The field’s autocomplete attribute (for example, a value meaning “postal code” or “email”). When this is present and correct, browsers mostly get it right.
- The field’s name and id, and whether they look like “zip,” “postal,” or “email.”
- The label text near the field and the field’s position relative to its neighbors.
When those clues are missing, generic, or contradictory, the browser falls back on order and proximity. If the email field sits right after the address block, or a field’s code name is vague, the browser can shift its guesses by one slot. The result is the email landing in ZIP, or a phone number landing in the address line.
There’s a second, less obvious cause: the visitor’s saved autofill profile may itself be wrong. If their browser once stored an email address in the postal code slot, it will keep filling it into every form on every site. You can’t fix that from your side, but it explains why the problem sometimes shows up for one person repeatedly and nobody else.
What you can control on an Altru web form
Honestly, not a lot of the underlying markup. Altru web forms are built and rendered by Blackbaud, and the field attributes browsers rely on are generated by the platform rather than set in the form designer. As far as we know, there isn’t a setting that lets you assign autocomplete values per field. If you’re not sure, ask Blackbaud support directly, and include a screenshot plus the browser and version where it happened. A specific, reproducible report is far more likely to get a platform fix than a general complaint.
Things worth trying within the form itself:
- Reproduce it. Create a clean test profile in Chrome and Safari with a fake name, address, and email. Fill the live form with autofill and note exactly which fields shift. Test on a phone too, since mobile autofill behaves differently.
- Check field order and labels. If your form lets you rearrange fields or edit label text, keep the standard sequence browsers expect: name, email, phone, then street, city, state, ZIP. Use plain labels like “ZIP code” and “Email address” rather than creative wording.
- Remove fields you don’t need. Optional extras sitting between the address and email blocks give the browser more chances to misalign.
- Be careful with page scripts. Some teams add JavaScript on their own website page to patch field attributes. Whether that works depends on how the form is embedded on your site; if the form loads in a frame from a different domain, your page scripts can’t reach it. Test thoroughly before relying on it, and expect it to break if Blackbaud changes the form.
Catching bad ZIP codes after the fact
Even if you can’t stop every misfire, you can stop it from sitting unnoticed in constituent records.
- Build a constituent query on address ZIP/postal code where the value contains “@”, or contains letters for U.S. addresses. Save it and run it weekly.
- Check the record’s email field. In most cases the correct email is also stored where it belongs, so the fix is simply clearing or correcting the ZIP. If the ZIP is missing entirely, the transaction or payment details may show the billing ZIP.
- Fix before mailings. Bad ZIPs mostly hurt you at print time: returned renewal notices, failed address standardization, and skewed geographic reports. Make this query part of your pre-mailing checklist.
- Watch for duplicates. A visitor whose address didn’t match their existing record may have been created as a new constituent. Compare the query results against existing records with the same name and email.
When you want control of the form itself
The root fix is a form whose fields carry correct autocomplete attributes and validate ZIP format before submission, which is hard to achieve when the markup isn’t yours to edit. That’s one reason some organizations move ticket, membership, and donation purchases to Social Good Checkouts, a branded, mobile-friendly checkout that replaces Altru web forms and writes the data back to Altru. Whatever you use, test autofill on real devices before launch.
Quick answers
Is this a problem with the visitor’s computer?
Sometimes. A corrupted saved address in their browser will misfill every form. If it’s happening to many different visitors, the form’s field markup is the more likely cause.
Can I tell visitors to turn off autofill?
You can add a short note asking people to double-check their address, but most won’t read it. Cleanup queries are more reliable than instructions.
