A code field that phones, browsers and password managers can fill reliably has four things: one input rather than one box per digit, autocomplete="one-time-code", a number keypad without type="number", and no paste blocking. This is the markup web.dev recommends, with a visible label added:

<label for="otp">Verification code</label>
<input id="otp" name="otp" type="text" inputmode="numeric"
       autocomplete="one-time-code" pattern="\d{6}" required>

Paste yours below. The checker reads the attributes the way a browser would and cites the standard behind each result.

Why does autocomplete="one-time-code" matter so much?

The HTML standard defines one-time-code as the autofill field name for a "one-time code used for verifying user identity". Apple's developer documentation lists it next to username and current-password, and says explicit values support login flows "that couldn't otherwise be detected by Password AutoFill's heuristics". Without it, the phone has to guess from the page. web.dev puts it this way: with the attribute set, when an SMS arrives while the form is open, "the operating system will parse the OTP in the SMS heuristically and the keyboard will suggest the OTP". web.dev wrote in 2020 that this works on Safari 12 and later on iOS, iPadOS and macOS.

autocomplete="off" says something different. The HTML standard uses it for values the browser should not remember and prefill, and even names a bank's one-time key as an example. It does not tell the browser that the field takes a one-time code, so phones and password managers are left to guess. A form-level autocomplete="off" applies to every field in the form that does not set its own value, so the checker reports it on the code field too.

Are one-box-per-digit code fields a problem?

Often, yes. W3C's Understanding document for WCAG 2.2 success criterion 3.3.8, Accessible Authentication (Minimum), level AA, names this exact failure: a code split into separate fields where "trying to paste the entire code only fills in one digit in the first input". The same document says a site that requires manual transcription of a code is not compliant, and that people must be able to paste the code and let the browser fill it. Boxes pass only if your script catches a paste or a suggestion in any box and spreads it across all of them. One input styled to look like boxes avoids the problem entirely.

What is wrong with type="number"?

A code is a string of digits, not a number. web.dev: type="number" shows up and down buttons that change the value "and may remove preceding zeros", so a code such as 042917 can lose its first digit. Use type="text" with inputmode="numeric", which opens the number keypad on phones without treating the code as a number.

What should the text message itself say?

End it with a line that names your site and the code, such as @example.com #042917. That is the origin-bound format from the WICG draft: the last line holds "@" and the host, one space, then "#" and the code, and nothing may follow that line, not even a newline. A browser that follows it offers the code on that site and "should not assist" on an unrelated one, which stops a look-alike page from getting the code filled in. web.dev gives the same layout for Chrome's WebOTP API, with optional readable text first, the @host #code line last, and 140 characters or less in total. Open the optional SMS box in the checker to test your template.

What can this checker not see?

Event listeners added from your JavaScript files. A paste handler in a script file is invisible in pasted markup, so paste a real code into the live page as a final test.
CSS that hides or covers the field, and fields rendered inside an iframe from another origin.
How each phone and password manager behaves in practice. The checks follow the published standards; the only full test is a real code on a real phone.

Why does the checker mention MagicLess?

MagicLess is the Chrome extension this site belongs to: it finds a fresh code in a person's connected Gmail inbox and offers a Fill button on the login page, without submitting the form. The last result shows whether it would recognize your field, using the extension's own field rules (checked against version 0.1.9 on September 28, 2026). It looks for a field marked one-time-code or labelled as a verification code, and for page text that says the code was emailed. If your page asks for an authenticator-app code or a texted code, it stays quiet on purpose, because it only reads email. For how people run into the same field from the other side, see accessible ways to find verification codes and what Chrome fills on its own.

Sources

All pages read September 28, 2026.

One-Time Code Field Checker: Autofill, Paste and WCAG

Paste your code field