Start with the value and its type
A type conversion mistake happens when JavaScript treats a value as a different type from the one you expected. A number entered into a form, for example, can arrive in your code as a string. If a calculation produces a surprising result, inspect both the value and its type before changing the calculation.
You can try the examples in a browser developer console. They use standard JavaScript supported by browsers with ECMAScript 2015 or later; no packages or build tools are required. Log related values together: console.log(quantity, typeof quantity, price, typeof price). This can reveal a string such as '2' where you expected the number 2. Remember that console displays can make strings and numbers look similar, so the typeof output matters.
Trace the operation that changes the meaning
The plus operator is a frequent source of confusion because it can add numbers or join strings. Consider const quantity = '2'; const price = 5; console.log(quantity + price). The result is '25', not 7: one operand is a string, so JavaScript joins their text. By contrast, subtraction attempts numeric conversion, so '2' - 5 produces -3. Different results from these operators are a clue to inspect the operands, not a reason to swap operators until the output looks right.
Comparisons can be surprising too. Two strings may be compared as text: '10' < '2' is true because the comparison follows character order, not numeric order. Convert and validate values before a comparison that is meant to be numeric. Prefer strict equality, ===, when you want to know whether values are equal without the type conversion performed by ==. For example, '2' === 2 is false; that result helps expose a type mismatch.
Check where the input came from
Work backward from the incorrect result to the point where each value entered your program. Form field values are strings, including values from inputs intended for numbers. URL parameters are also strings. Data returned by JSON.parse, on the other hand, can contain numbers, strings, booleans, null, arrays, or objects, depending on the JSON. Do not assume that every value reaching the same function has the same type.
A useful debugging sequence is to log the raw input, log its type, perform the conversion once, and log the converted result. Then test an ordinary value, an empty value, whitespace, and invalid text. For a form quantity, the distinction matters: Number('2') gives 2, but Number('') and Number(' ') both give 0. If blank input should mean “missing,” check for it before calling Number.
Convert deliberately and validate the result
For a field that should contain a complete number, you might use const raw = input.value.trim(); if (raw === '') { /* show a missing-value message */ } else { const quantity = Number(raw); /* validate quantity here */ }. Number('12px') produces NaN rather than accepting part of the string. If your application needs a nonnegative whole quantity, check Number.isInteger(quantity) && quantity >= 0 before using it. The right validation rule depends on what the value represents.
Use Number.isNaN(value) to detect NaN after conversion. The expression typeof NaN returns 'number', so typeof alone cannot confirm that a usable number was produced. Number.isFinite(value) is another useful check when a calculation requires a finite number. Avoid silently replacing every invalid input with zero: that can hide the original problem and make later results harder to explain.
Be cautious with parseInt and parseFloat. They can stop parsing when they encounter an invalid character, so parseInt('12px', 10) returns 12. That behavior is useful for some deliberately mixed text, but it is usually a poor way to validate a field that must contain only a number.
Make the fix easy to verify
Once you find the conversion mistake, make the type boundary explicit. Convert incoming text near the point where it enters your calculation, validate the converted value, and pass a known type to the rest of your code. If several functions each perform their own conversion, an invalid value may behave differently in each place.
Finally, repeat the case that exposed the bug and try nearby cases: '2', '', ' 2 ', 'two', and a decimal or negative value if those are relevant. Check both the result and the message shown for invalid input. A good fix does more than make one example pass; it makes the expected type clear and prevents unexpected input from quietly changing the calculation.
