JSON Number Types: Integers, Floats & Precision

How Numbers Work in JSON

Unlike many programming languages, JSON has only one number type. There is no distinction between integers and floating-point values at the syntax level — both are just "numbers." A JSON number is a sequence of digits that may include a decimal point and/or an exponent. Numbers are never quoted (a quoted number is a string).

Valid Number Formats

Here are all the valid ways to express numbers in JSON:

{
  "integer": 42,
  "negative": -17,
  "zero": 0,
  "float": 3.14159,
  "negativeFloat": -0.5,
  "smallDecimal": 0.001,
  "scientificPositive": 1.5e10,
  "scientificNegative": 2.99792458e-8,
  "scientificUpperE": 6.022E23,
  "largeNumber": 9007199254740991,
  "negativeZero": -0
}

Number Syntax Rules

JSON number syntax has specific requirements:

• No leading zeros. 042 is invalid. Only 0 itself can start with zero, or 0.5 for decimals.
• Decimal point needs digits on both sides. .5 is invalid — write 0.5. Similarly, 5. is invalid — write 5.0 or just 5.
• Exponent uses e or E. Both 1.5e10 and 1.5E10 are valid. The exponent can be positive (e+10 or e10) or negative (e-8).
• No hex, octal, or binary. 0xFF, 0o77, and 0b1010 are all invalid in JSON. Use decimal integers only.
• No special values. NaN, Infinity, and -Infinity are not valid JSON.

Invalid Number Formats

These are all parse errors in JSON:

// ❌ All of these are INVALID JSON numbers
{
  "leadingZero": 042,        // No leading zeros
  "leadingDecimal": .5,      // Must be 0.5
  "trailingDecimal": 5.,     // Must be 5.0 or 5
  "plusSign": +42,            // No leading + sign
  "hex": 0xFF,               // No hexadecimal
  "octal": 0o77,             // No octal
  "binary": 0b1010,          // No binary
  "nan": NaN,                // Not valid in JSON
  "infinity": Infinity,      // Not valid in JSON
  "negInfinity": -Infinity,  // Not valid in JSON
  "quoted": "42",            // This is a string, not a number
  "underscore": 1_000_000    // No separators
}

Real-World Number Examples

Here's a practical example showing how numbers are used in a financial transaction record:

{
  "transaction": {
    "id": "TXN-20250120-001",
    "amount": 1299.99,
    "tax": 107.25,
    "discount": 50.00,
    "total": 1357.24,
    "exchangeRate": 0.85,
    "quantity": 3,
    "weight": 2.5,
    "dimensions": {
      "length": 30.5,
      "width": 20.0,
      "height": 15.75,
      "unit": "cm"
    }
  }
}

The Precision Problem

JSON numbers are parsed as IEEE 754 double-precision floating-point in most languages (including JavaScript). This means integers are only safe up to 2⁵³ − 1:

{
  "safe": 9007199254740991,
  "unsafe": 9007199254740993,
  "twitterId": "1234567890123456789"
}

The value 9007199254740993 cannot be exactly represented in JavaScript. Parsing it will silently round it to 9007199254740992. This is why Twitter and other APIs return large IDs as strings (note the quotes around twitterId above).

When to Use Strings for Numbers

Use string-encoded numbers when:

• IDs exceed 2⁵³ − 1. Database IDs, Snowflake IDs, and other 64-bit integers should be strings to prevent precision loss.
• Exact decimal precision is required. Financial amounts like "19.99" should be strings if you need to preserve exact decimal places across all platforms.
• Leading zeros matter. ZIP codes like "07201" and phone numbers must be strings because JSON numbers strip leading zeros.

Floating-Point Surprises

Classic floating-point issues apply to JSON numbers as well:

// In JavaScript after parsing JSON:
0.1 + 0.2          // → 0.30000000000000004
0.3 - 0.1          // → 0.19999999999999998
1.005 * 100        // → 100.49999999999999

These are not JSON bugs — they're inherent to IEEE 754 floating-point arithmetic. For financial calculations, either use integer cents (store 1299 instead of 12.99) or use a decimal math library.

Scientific Notation Use Cases

Scientific notation is useful for very large or very small numbers:

{
  "physics": {
    "speedOfLight": 2.998e8,
    "planckConstant": 6.626e-34,
    "avogadro": 6.022e23,
    "electronMass": 9.109e-31
  },
  "astronomy": {
    "earthSunDistance": 1.496e11,
    "galaxyDiameter": 9.461e20
  }
}

Writing 2.998e8 is more readable and less error-prone than 299800000.

Common Mistakes to Avoid

• Quoting numbers accidentally: "42" is a string, not a number. Many APIs return numeric strings, and consumers forget to parse them.
• Leading zeros: 007 is not valid JSON. Use 7 for numbers or "007" for codes that need leading zeros.
• Assuming integer precision: Large IDs like 1234567890123456789 will lose precision in JavaScript. Use strings for 64-bit integers.
• Using NaN or Infinity: These are not JSON values. Serialize them as null or a string representation like "NaN".
• Numeric separators: 1_000_000 is valid in JavaScript and Python but not in JSON. Remove underscores.