Why does cleaned 1.005 become 1.00 with toFixed(2)?

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.

Parsing succeeds but the expected decimal display does not

The marked decimal contains U+200B after its decimal point and initially converts to NaN. Its precision and fixed outputs are the string NaN too. Cleanup produces 1.005, which converts successfully, but the seventeen-significant-digit observation shows 1.0049999999999999. The two-decimal fixed result is 1.00. Saving all three stages explains why a successful Number conversion can coexist with a result that surprises someone reasoning about exact decimal 1.005. The cleaner did not choose a rounding mode or delete a decimal digit; its output string is retained unchanged beside these independent numeric observations.

Midpoint controls keep the explanation concrete

Plain 1.005 gives the same precision and fixed strings without cleanup. For 2.55, the recorded precision string is 2.5499999999999998 and toFixed(1) yields 2.5. Exact-quarter control 1.25 displays 1.2500000000000000 at the chosen precision and toFixed(1) yields 1.3. That contrasting row prevents the blanket claim that this method always rounds a final five downward. We also record fixedType as string in every row. A formatting return value is therefore not a new numeric type or evidence that the original decimal representation has been preserved as exact arithmetic.

Select an arithmetic contract before display formatting

When an application requires a particular decimal rounding rule, define its representation, precision and rounding behavior independently of invisible-character cleanup. Keep the original decimal text for review. A fixed display method on Number cannot establish that a decimal input was stored exactly, and adding more removal passes does not address this boundary. This page does not prescribe a financial calculation system, test a decimal library or recommend a universal arithmetic workaround. Its small matrix supplies concrete evidence for diagnosing a display discrepancy, with the exact Number precision and formatting calls available in the downloadable harness.

The measurements do not generalize every rounding case

We use four authored strings, one runtime and two fixed-digit counts. The seventeen-digit field is a decimal diagnostic for the represented Number, not a complete dump of the binary bits. No locale formatting or parsing of a currency symbol occurs. The prior NumberFormat guide asks whether localized output can be parsed back; this test uses toFixed and examines representation before a fixed decimal display. The homepage does not perform these calculations. Neither a successful parse nor an expected formatted result identifies the origin of pasted text or tests a statistical watermark or AI detector.

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