Why do cleaned fullwidth digits still fail Number conversion?

Measured inputs and outputs

These are locally constructed test strings, not evidence that Claude inserts these characters. We executed the saved homepage script snapshot with a minimal DOM harness and compared exact strings. The invisible-checkbox state and dash mode appear in each row. The observations below test this page's specific question. Destination observations run independently on the exact input and cleaned strings in the recorded Node runtime. We make no detector-score or statistical-watermark removal claim.

Deletion does not convert the numeral width

The first input has fullwidth one, U+200B and fullwidth two. The homepage deletes the marker and returns the two fullwidth digits. Number still produces NaN, and our explicit ASCII-digit regex still rejects the result. An independent NFKC branch instead yields ASCII 12, which passes that regex and converts to twelve. Before deletion, the NFKC branch retains the marker between its converted digits and still fails. This ordering matters: the compatibility mapping and selected-character cleanup solve different obstacles. Neither stage should be credited with the other’s transformation when diagnosing a rejected pasted field.

The circled control exposes a wider acceptance policy

Plain fullwidth １２ has the same conversion outcome without any selected marker, while the ordinary ASCII reference succeeds immediately. Circled ⑫ is also transformed to ASCII 12 by NFKC, despite being a single source code point rather than two fullwidth digits. That fourth row is the reason this page treats compatibility normalization as a policy choice. A developer intending only width conversion could inadvertently accept another representation as well. The observer records the normalized spelling, regex acceptance and Number result independently, allowing the choice to be reviewed without assuming a successful parse proves that the original format was allowed.

Decide which source representations are permitted

For a decimal field, first write down the source formats the application supports. If fullwidth digits are legitimate, choose a deliberate mapping and validate its output against the complete field grammar and numeric range. If the source contract requires ASCII, report a helpful validation error instead of silently widening it. Preserve the original string for correction and review. Our ASCII regex accepts only one or more digits; it does not allow signs, decimal points or grouping separators. Even a successful Number result in this table would not validate those additional forms or establish an appropriate policy for account identifiers, document numbers or monetary values.

Compatibility conversion has a bounded demonstration

The earlier normalization guide includes a ligature and shows that NFKC is not a general invisible-character remover. This experiment asks a separate destination question: which numeric spellings become admissible when a developer adds NFKC after cleanup? Its evidence is four synthetic inputs and exact observed conversions, not a recommendation to normalize all identifiers. We do not test every compatibility character, localized numeral parser or browser numeric field. The unchanged homepage never performs NFKC. No claims about watermark presence, detector behavior or the origin of the fullwidth string follow from a successful conversion in our local observer.

Reproduce this test

Save reproduce.cjs and tested-app.js in the same folder. Run the command below with Node.js. The harness prints its runtime, script SHA-256 and every measured row. Compare those rows with the original record. Using a newer script or runtime creates a new experiment; retain the version information with your rerun.

node reproduce.cjs