Your app asks the user to type a six-digit code sent by SMS. Which HTML autocomplete value makes phones offer that code, and how should the input be marked up?

## The token `one-time-code` is one of the autofill field names defined in HTML, alongside `username`, `current-password` and `new-password`. It states that the field expects a short, single-use verification code — the kind delivered by SMS for two-factor sign-in or transaction confirmation. The markup is deliberately boring: ```html <label for="otp">Verification code</label> <input id="otp" name="otp" type="text" inputmode="numeric" autocomplete="one-time-code"> ``` `type="text"` with `inputmode="numeric"` is the usual choice over `type="number"`, because a verification code is a string of digits rather than a quantity — leading zeros matter, spinners and scroll-to-change do not belong on it, and grouping separators are meaningless. ## What the token buys On mobile platforms the operating system or browser watches for an arriving message that looks like a verification code for the site the user is on. When the focused field is marked `one-time-code`, the code is offered as a suggestion directly above the keyboard. One tap fills it. The user never switches to the messaging app, never memorises six digits, never comes back to a page that has meanwhile been evicted from memory. That last point is the real payoff. App-switching mid-flow is where verification funnels leak: the user leaves to read the message, gets distracted, returns to a reloaded page or an expired code. Eliminating the switch is worth more than any amount of styling on the input. Behaviour differs across platforms in the details — how the message must be formatted, whether the site's origin must appear in it, whether a suggestion appears at all — so treat the token as an enabling signal rather than a guarantee. The flow must remain fully usable by typing. ## Why the six-box design fights it A popular visual treatment gives each digit its own square box, with scripting to advance focus as you type. It photographs well and it fights every mechanism that would have helped: - **Autofill.** The token describes one complete code. Six fields each claiming to be *the* one-time code is incoherent, and the platform suggestion has no single destination. - **Paste.** Users who copy the code from the message expect one paste to land it. Distributing pasted characters across six inputs requires code you have to write and get right, and many implementations simply drop everything after the first character. - **Correction.** Backspacing through auto-advancing boxes is a well-known usability sore point, and it is worse with a screen reader, which encounters six unlabelled single-character fields instead of one labelled control. If the design is non-negotiable, the honest approach is a single real input that owns the value, label, autofill token and paste behaviour, with the boxes as presentation over it — but the simplest correct answer in an interview is that one input is what the platform expects. ## Things that quietly break it **Suppressing autofill.** `autocomplete="off"` on a verification code is a reflex worth resisting. `one-time-code` already conveys single use; the token is a description, not a request to remember anything. **Blocking paste.** Intercepting paste events on the field is sometimes justified as anti-phishing. It mainly punishes the ordinary user who copied the code, and pushes them to retype from a second device. **Missing label.** The field still needs a real `<label>` — the autofill token speaks to the platform, not to the user or to assistive technology. **Over-restrictive input filtering.** Stripping non-digits on every keystroke can conflict with how a suggestion is inserted, and it interferes with paste of a code that arrives with a space or a dash. Validate on submit instead of policing every character. ## Related but distinct There is also a scripted route where a page can be handed the message content programmatically rather than through the autofill dropdown; that is a JavaScript browser API and belongs to the browser-platform side of the boundary, not to your markup. The markup answer is the token — and the token alone already delivers the one-tap experience on the major mobile platforms without any script. For authenticator-app codes rather than SMS, the same token is still the right description of the field: it says "single-use verification code", and a password manager that stores the shared secret can use that to offer the current code the same way. ## The short version One labelled input, `inputmode="numeric"`, `autocomplete="one-time-code"`, paste allowed, validation on submit. Everything fancier is a chance to lose the one-tap fill you were trying to enable.