The keyboard adapts to the field

WM Keyboard reads what kind of field you’ve tapped into (email, phone number, password, and five others) straight from the app’s own field description, and quietly changes the keys on offer to match. None of this needs a setting: it’s the same keyboard reacting to what’s under your thumb.

An email field: the bottom-row comma has become @, and the period key's long-press offers .com, .net, .org, .edu, .co.

How the keyboard reads a field

Every field an app gives you carries an EditorInfo with a type (the same information Android’s own keyboards read). WM Keyboard turns that into one of eight FieldKind values: TEXT, EMAIL, URI, NUMBER, PHONE, DATE, TIME, DATETIME. Five of them (NUMBER, PHONE, DATE, TIME, DATETIME) are numeric-pad kinds and get a dedicated keypad instead of the letter layouts; the other three (TEXT, EMAIL, URI) keep the letters but adjust individual keys, covered below.

This detection is automatic and isn’t a setting you can turn off: it runs on every field focus, for every app, on both editions.

A password field is a separate signal entirely. It doesn’t get its own FieldKind (a masked text field reports FieldKind.TEXT, identically to an ordinary prose box), because the privacy behavior a password needs (suggestions off, nothing learned, clipboard cleaned up) applies just as much to a numeric PIN field as to a text one. Instead there’s a second, independent flag, secureField, computed from the field’s password variation (or, for a numeric field, its PIN variation) alongside FieldKind. A 4-digit PIN box is a good example of both firing together: it’s FieldKind.NUMBER (so it gets the numeric keypad) and secureField = true (so it gets every privacy rule below) at once.

Typing in email and web address fields

A URL field: the comma key has become /, with ? # & = on its long-press.

Email and URL fields keep the ordinary letter layout (you’re typing words either way), but two keys on the bottom row only change to match:

• Email fields (FieldKind.EMAIL): the comma key becomes @, and the period key’s long-press gains domain endings ahead of its usual alternates: .com, .net, .org, .edu, .co.
• URL fields (FieldKind.URI): the comma key becomes / (long-press ?, #, &, =), and the period key’s long-press gains .com, .org, .net, www., https://, /.

The swap only touches the bottom row on purpose: a Dvorak layout has real . and , letter keys elsewhere on the board, and those stay untouched. It’s also scoped to the letters layer only; switching to the symbols page shows the normal punctuation. Like field detection itself, this isn’t a toggle anywhere in settings; it’s on whenever the field kind matches.

Typing in number, phone, date, and time fields

A phone-number field: a 4-by-4 dial pad in phone order, not calculator order.

The five numeric-pad field kinds each get their own 4-column keypad, with digits arranged phone-pad style (1-2-3 on top, not 7-8-9 like a calculator), delete in the top-right corner, enter in the bottom-right, and the remaining two keys tailored to what that field type needs:

Field kind	Right column	Bottom-left	Bottom-right	Notes
Number	- (long-press + % * /), space	. (long-press :)	,	Minus and decimal always shown, even if the field didn’t ask for them
Phone	- (long-press ( ) / .), space	* (long-press ,)	# (long-press ;)	Zero key’s long-press adds +
Date	/ (long-press :), -	.	,	Covers 20/07/2026, 2026-07-20, 20.7.26 styles
Time	: (long-press .), space	.	-	Colon-led for 17:45
Date & time	/ (long-press .), :	-	space	Date and time separators together

These five keypads are shared across every built-in layout (only the default QWERTY layout defines them, and every other language layout inherits the same set), but a custom .wmlayout.json can override any of the five with its own key rows if it needs to.

The keypad shows up whenever the field kind calls for it, with one exception: if focus has actually been rerouted to something that needs letters, such as an in-panel search box (emoji, dictionary, clipboard, media), a plugin’s own text field, or the typing-test tool, the letter layout stays up instead, since a digits-only pad would leave those impossible to type in.

WM Keyboard›Key press›Key popup›Popup on number pads

The floating character bubble that normally appears above a held key is off by default on these five keypads. Turn on Popup on number pads (only shown once Key popup itself is on) to bring it back. It’s off by default because, over a PIN, echoing each digit large enough to read is closer to a shoulder-surfing risk than a help.

Not the Numpad tool

Don’t confuse this with the standalone Numpad tool in the toolbox, which is a separate keypad panel you open on purpose from any field. Its own phone-vs-calculator digit order is a toggle under that tool’s own settings and has no effect on the field-adapted keypads described here; those are always phone-pad ordered.

Typing in a password field

A password field: the suggestion strip stays hidden, and pasting into it wipes the clip afterward.

secureField drives a wider set of behavior than just “hide the suggestion strip”:

• Suggestions never show. Password variations force the suggestion strip off unconditionally (the one case WM Keyboard›Typing›Suggestions›Suggestions in every field can’t override), since that setting exists specifically to make hidden strips show anyway on ordinary fields.
• Autocorrect and gesture typing turn off too, and not only in password fields. These, along with on-device learning, are gated on a broader check than secureField alone: it also excludes every structured field kind (EMAIL, URI, NUMBER, PHONE, DATE, TIME, DATETIME), not just secure ones. A keypad has no words to autocorrect, and an email address shouldn’t be second-guessed either. Only a plain TEXT field that also isn’t secure gets the full typing-intelligence treatment.
• Phonetic (Avro) composing is the one exception: it keeps running everywhere, including password fields. Bengali transliteration turns roman key presses into Bengali as you type, and that step isn’t gated on the same check at all: turning it off in a secure or structured field would mean the roman keys commit untransliterated instead of no Bengali being produced. Only the suggestion-feeding side of composing (plain English composing, which exists purely to feed autocorrect and suggestions) is gated alongside autocorrect and gesture typing.
• Nothing is learned. The same gate feeds WM Keyboard›Privacy›On-device learning›Learn from typing: typing in a password field, or any structured field, never reaches the on-device learning dictionary.
• Voice typing refuses to start. Both the voice panel and the toolbar strip’s dictation toggle decline while a secure field is focused. The toolbar toggle shows a toast reading “Voice typing is unavailable in password fields,” while the panel shows its own inline notice instead (“Voice input is unavailable in password fields.”).
• Clipboard history stops recording while a secure field has focus, so new copies (and screenshot-to-clipboard captures) are skipped for as long as it’s focused.
• Pasting into a password field can wipe the clip afterward. See Clipboard: passwords are handled deliberately for the full paste-time purge behavior and its setting.

Password manager suggestions are a separate feature

WM Keyboard›Typing›Suggestions›Password manager suggestions shows your system autofill service’s saved-login chips inline in the suggestion strip. It isn’t gated by secureField (it’s tied to a login field, not a secure one), and the chips are drawn entirely by your password manager: the keyboard is only told their size and never sees the username or password inside them. It needs Android 11+ and a password manager set as your system autofill service, and turns itself off automatically while incognito mode is on. The system’s smart replies come down the same channel but have their own toggle, and aren’t tied to field type at all.

When an app gets its own field wrong

There’s no manual override for field detection: no setting to force a field to be treated as a password or an email box. Detection reads only the field’s real inputType, every time it’s focused, and there’s nothing else to configure.

Two related things exist, but neither is a correction for a misreporting app:

• FORCE_ASCII: if a field sets this flag and your current layout isn’t Latin-script, the keyboard switches to your first enabled Latin layout for that field (the app declaring a hard constraint, not a workaround for bad detection).
• hintLocales: an app can hint which language a field expects; honored only if you already have that language enabled. It’s advisory, and never overrides field-kind detection.

Keyboard modes look like an override at first glance (you can manually pin the built-in Passwords mode over any field), but a manually pinned mode only changes cosmetic and toolbar state (theme, toolbar tools, symbol row, emoji row). It does not touch secureField, so it can’t turn on suggestion-hiding, learning-off, or clipboard purging for a field an app has genuinely mislabeled. If a login field is reported as plain text, pinning Passwords dresses the keyboard for it but doesn’t restore the actual privacy protections; those come only from the field’s real, correctly-reported type.

Options

Setting	Default	Path
Suggestions in every field	On	WM Keyboard›Typing›Suggestions›Suggestions in every field
Contact emails in email fields too	On	WM Keyboard›Typing›Suggestions›Contact emails in email fields too
Password manager suggestions	On (Android 11+)	WM Keyboard›Typing›Suggestions›Password manager suggestions
Popup on number pads	Off	WM Keyboard›Key press›Key popup›Popup on number pads
Forget after pasting a password	On	WM Keyboard›Tools›Clipboard›History›Forget after pasting a password
Learn from typing	On	WM Keyboard›Privacy›On-device learning›Learn from typing
Add words to the system dictionary	Off	WM Keyboard›Privacy›On-device learning›Add words to the system dictionary

Contact emails in email fields too only shows up once Suggest contact emails itself is on; when it is, a contact-email completion still appears in an email field even if the app asked for a hidden strip there, while other suggestions in that field stay hidden.

Details and edge cases

• A password field’s FieldKind is TEXT, not a dedicated kind. If you’re reading behavior off the field kind alone, remember password status is the separate secureField flag layered on top: a numeric PIN field carries both FieldKind.NUMBER and secureField = true simultaneously.
• The typing-intelligence cutoff is broader than “passwords only.” Autocorrect, gesture typing, and learning all turn off for every field kind except plain, non-secure TEXT, which includes email and URL fields, not just passwords and numeric pads. Phonetic (Avro) composing is the one exception: it keeps running in every field, secure or structured, since it exists to transliterate roman keys into Bengali rather than to feed suggestions.
• The suggestion strip is force-emptied a second time, independent of the strip-hiding check above, as a backstop specifically for secure fields.
• The email/URL key swap has no toggle. It’s derived purely from field kind and layout mode (letters layer only); there’s nothing to turn off short of the field itself not being an email or URL field.
• A custom layout can override any of the five numeric keypads by defining its own NUMBER/PHONE/DATE/TIME/DATETIME layer; anything it doesn’t define falls back to the shared ones described above.
• No edition split. Field-kind detection, the key swaps, the five keypads, and every secure-field behavior on this page work identically on the full and lite builds.

For symbol-page cycling and how a keyboard mode can bind itself to a field kind, see Modes & the symbol row. For the paste-time clipboard purge in full, see Clipboard manager.