Why Chrome autofill fails on government and long application forms
Why Chrome autofill fails on government and long application forms
Browser autofill feels magical on a checkout page and useless on a permit renewal. That is not a bug you can fix in settings — it follows directly from what browser autofill is.
What browser autofill actually is
It is a checkout accelerator. It was built to solve one commercial problem: people abandoning purchases rather than typing an address again.
It works by recognizing a small, fixed vocabulary of field types:
- given name, family name, full name
- street address, city, province/state, postal code, country
- email, phone
- payment card number, expiry, cardholder name
Against that vocabulary it matches using autocomplete attributes, field names, and heuristics over labels and placeholders.
Within its domain it is genuinely excellent. Outside it, it has nothing to offer.
Why government forms fall outside it
Look at what a typical Canadian government form asks for:
| Field | In the browser's vocabulary? |
|---|---|
| Given name, address, email, phone | ✅ |
| Social Insurance Number | ❌ |
| Immigration document number, UCI, permit number | ❌ |
| Date of entry to Canada | ❌ |
| Previous addresses for the last ten years | ❌ |
| Employment history with dates and duties | ❌ |
| Spouse's details | ❌ |
| Each child's name and date of birth | ❌ |
| Health card number | ❌ |
| Reference or file numbers | ❌ |
Autofill can complete four of those. The other nine are the form.
The same holds for job applications: an ATS wants your employment history, education, references, work authorization and salary expectations. A browser has none of it — which is why autofill accuracy collapses on long ATS forms and stays high on the shipping-address step of a store.
The structural obstacles
Even for fields the browser could match, these forms defeat it in four common ways.
Custom form components. Modern portals build inputs out of divs and JavaScript rather than plain HTML inputs. The browser sees no field to fill.
Iframes. A form section embedded from another origin is a separate document, and autofill does not reach across.
Multi-step wizards. The form renders one section at a time. Autofill acts on what is on screen; the other twelve sections do not exist yet.
Dynamically generated field names. field_a7f3c2 tells a heuristic nothing. Some systems regenerate these per session.
Anti-automation measures. Some government portals deliberately discourage programmatic filling.
Why the wrong value sometimes appears
Autofill guesses. On an ambiguous field — "Address" on a form that wants your employer's address — it may confidently insert your home address.
This is more dangerous than filling nothing, because a blank field is obvious and a wrong one is not. Review every field after any autofill, on any form, before submitting.
Should you store sensitive data in browser autofill?
Generally, no.
- Browser profiles are commonly synced to a cloud account, and the data is available to anyone with your unlocked device or profile.
- They are not designed for identity documents — there is no field type for a SIN, no expiry tracking, no record of where you used it.
- The security model is the browser's, and the browser is the most-attacked application on your computer.
Keep names, addresses and phone numbers there if you like. Keep SINs, passport numbers and immigration document numbers out. See Who can legally ask for your SIN.
What closes the gap
For the forms browser autofill cannot reach, you need something with three properties it does not have:
- The right field vocabulary — immigration documents, SIN, employment history, family members, health card numbers, reference numbers.
- Label-based matching, so it works on fields whose names are meaningless.
- Household awareness, so a form asking about your spouse and each child can be filled from stored records rather than from memory.
And regardless of what fills the form: review before submitting. No autofill of any kind should be trusted blind on a document with consequences.
How my-id.ca helps
This gap is the reason my-id.ca exists.
Your profile holds the fields these forms actually ask for — identity documents, immigration details, employment history, and your spouse, children and emergency contacts as their own records — and the Chrome extension matches by label and context rather than only by attribute, so it reaches fields the browser skips. The same profile fills PDFs, which browser autofill cannot touch at all.
Two deliberate design choices worth knowing:
- Autofill is off on every site until you turn it on for that site. Nothing is offered anywhere by default.
- You review before submitting. The review screen shows every value and where it came from, grouped by confidence, so uncertain matches get your attention rather than slipping through.
Your data is encrypted, stored on Canadian servers, and never sent to a third-party AI provider — a different arrangement from a browser profile synced to a consumer cloud account. When autofill does not fire, there is a troubleshooting guide.
Next steps
- Use autofill on websites
- When autofill does not work
- Review every field before you send
- Government and official forms
Important: this is general information, not legal advice
This article is general information about working with documents — it is not legal, technical, or professional advice, and my-id.ca does not provide legal or professional consultation. my-id.ca is not a government agency, law firm, lawyer, or licensed advisor, and is not affiliated with or endorsed by Google, Microsoft, Apple, Mozilla, or any government body.
Browser behaviour and website implementations change frequently. Always review every field on a form before submitting it, whatever filled it, and confirm submission requirements with the agency (canada.ca and ontario.ca). For advice about your individual circumstances, consult a qualified professional. If anything in this guide differs from an official source, the official source is correct.
Frequently asked questions
- Why doesn't Chrome autofill work on government websites?
- Browser autofill matches a small fixed set of field types drawn from e-commerce checkout — name, address, email, phone, payment card. Government forms ask for SIN, immigration document numbers, previous addresses, employment history and dependant details, which fall entirely outside that vocabulary.
- Why does autofill work on some sites and not others?
- It depends on how the form is built. Fields with standard autocomplete attributes and recognizable names get matched. Custom components, fields inside iframes, dynamically generated names, and multi-step wizards that render one section at a time generally defeat it.
- Can I add custom fields to Chrome autofill?
- Chrome's profile holds a fixed set of entries — names, addresses, phone numbers, emails, payment methods. There is no supported way to add arbitrary fields such as a SIN, a permit number or an employment history entry.
- Is it safe to store sensitive data in browser autofill?
- Browser profiles are tied to the browser and often synced to a cloud account, and the data is available to anyone who has your unlocked device or profile. They are also not designed for identity documents. Most people should keep a SIN or passport number out of browser autofill.
- Why does autofill put the wrong value in a field?
- It guesses from field names and labels. Ambiguous or unusually named fields cause mismatches, which is why a mailing address can land in an employer address field. Always review a form after any autofill before submitting.
- What works better on long application forms?
- A tool built for the domain — one holding the field types these forms actually ask for, able to match by label rather than only by attribute, and able to handle multi-step forms. Whatever fills the form, review every field before submitting.