Numbers & Math
JavaScript uses a single number type for both integers (like 42) and floating-point decimals (like 3.14).
Featured Developer Sponsor • Zero-Token Protection
📋 Copy JavaScript Numbers & Precision Workarounds Snippet
// Safe Integer Limits & Arbitrary Precision
const maxSafe = Number.MAX_SAFE_INTEGER; // 9,007,199,254,740,991
const largeId = 9007199254740995n; // BigInt for 64-bit database IDs
// Currency / Decimal Precision Workaround
const toCents = (dollars) => Math.round(dollars * 100);
const total = (toCents(0.1) + toCents(0.2)) / 100; // 0.30 exact
// Safe Parsing
const parsed = Number.parseInt("42px", 10); // 42
const isValid = Number.isFinite(parsed) && !Number.isNaN(parsed);⚠️ 5 Fatal Traps & JavaScript Pitfalls
Trap #1: 0.1 + 0.2 !== 0.3 IEEE 754 Floating Point Trap
JavaScript numbers are 64-bit double-precision floats. Base-10 decimals like 0.1 have repeating binary fractions, resulting in
0.30000000000000004. For financial calculations, store integer cents.Trap #2: NaN !== NaN Self-Equality Trap
NaN is the only value in JavaScript that is not equal to itself: NaN === NaN evaluates to false. Always check with Number.isNaN(val).Trap #3: BigInt and Number Mixing TypeError
You cannot perform arithmetic between BigInt and Number:
10n + 5 throws TypeError: Cannot mix BigInt and other types. Explicitly cast types before operations.Trap #4: parseInt() Without Radix 10
Omitting the radix (
parseInt("08")) in older engines parsed strings with leading zeros as octal numbers. Always supply the radix: parseInt("42", 10).Trap #5: Integer Overflow Past Number.MAX_SAFE_INTEGER
Integers greater than 9,007,199,254,740,991 (2^53 - 1) lose precision, causing database IDs (like Twitter Snowflake IDs) to corrupt. Always parse large numeric IDs as strings or BigInt.
💬 Frequently Asked Questions
Sponsored Utility
While You're Here
Sponsored Recommendations
Advertisement