Mask does not switch when input becomes incompatible mid-entry

[edumt]

When using masks with overlapping valid prefixes, the initial branch selection works correctly on first input and when completing a mask. However, during typing, if the selected branch later becomes incompatible with the evolving input (while another mask would still be valid), the mask does not re-evaluate or switch branches.

I’m not entirely sure if this is a bug or expected behavior (or skill issue 😭 ), but it seems like the expected UX would be for the mask to switch dynamically when the input diverges from the currently selected mask.

In this example there are two masks:

Mask A: 11-digit numeric format
Mask B: 14-character format (12 uppercase alphanumeric characters + 2 digits)

Because both formats share compatible prefixes, initially Mask A is selected when the user starts typing numeric input. However, once Mask A is selected, the input becomes constrained by that mask. This prevents entering alphanumeric characters that would make the value invalid for Mask A but valid for Mask B:

The user starts typing numeric input → Mask A is selected
The mask “locks in” to Mask A
Alphanumeric input is blocked, even though Mask B would still be a valid match
Only after completing Mask A does switching become possible again

---

• OS: Windows 11 25H2
• Browser: Chrome Version 149.0.7827.115 (Official Build) (64-bit)
• Inputmask version: 5.0.9

[edumt]

This seems like a branch-selection policy question as much as a bug. If a mask branch becomes impossible after a later character while another branch is still valid, dynamic re-evaluation would improve UX, but it could also surprise users if earlier characters get reinterpreted too aggressively. A minimal repro with two overlapping masks and the exact character where the first branch becomes invalid would help define whether this should be default behavior or an opt-in mode.

I've updated the example (https://codepen.io/edumt/pen/QwdpyeZ) to better reproduce the issue.

The first few characters are accepted as either numbers or letters, and the mask is selected accordingly. However, if the input starts with numbers (e.g. 123), it won't accept any letters afterward, even though the alphanumeric mask should still be a valid match. Letters are only accepted once the numeric mask becomes "complete" (e.g. after 123.456.789-10), which makes it impossible to enter a valid alphanumeric value that begins with digits.