Does JSON support floating-point numbers?

Yes. JSON has a number type whose text form can include an optional fraction and an optional exponent, so values like 3.14159 and 1e-6 are valid JSON numbers. However, JSON itself does not define storage precision or a float vs integer distinction; that depends on parsers and runtimes. For large or very precise numbers, accuracy can be lost unless you plan for it RFC 8259, RFC 8259.

What the JSON specification allows

The JSON grammar defines a number as an optional minus sign, an integer part, and optional fraction and exponent parts. It forbids special values like NaN and Infinity. Implementations may impose limits on range and precision RFC 8259.

• Valid examples: 42, 3.14159, 1e-6
• Invalid examples: 3. (no digits after the decimal), Infinity, NaN

{"int": 42, "pi": 3.14159, "micro": 1e-6}

Invalid JSON example (will fail to parse):

{"bad": 3., "alsoBad": Infinity}

Why it fails: JSON requires at least one digit after a decimal point, and does not permit Infinity or NaN RFC 8259.

Can JSON represent large numbers accurately?

JSON itself does not fix a precision. For broad interoperability, the specification advises not to expect more range or precision than commonly available IEEE 754 binary64 (double precision) provides. With such software, all integers in the range [-9007199254740991, 9007199254740991] are represented exactly across implementations. Very large exponents (for example 1E400) or very long decimals may not round the same way everywhere RFC 8259.

Key takeaways for accuracy:

• Integers in [-2⁵³+1, 2⁵³-1] are interoperably exact with typical binary64-based software RFC 8259.
• Decimals are valid JSON, but binary floating arithmetic can introduce rounding in many languages; behavior varies by parser/runtime RFC 8259.
• Parsers may set limits on number size and precision RFC 8259.

Practical implications in real systems

Confirm the numeric representation used by both producer and consumer. A parser may offer decimal or arbitrary-precision options, but those are implementation features, not additional JSON syntax. Check round trips with representative values rather than assuming every runtime stores numbers identically.

When you need exact decimals or very large integers

If you must preserve exact values (financial amounts, cryptographic hashes, account or order IDs), do not rely on generic number parsing alone. Prefer one of these approaches:

• Serialize as strings and document the expected format.
• Use JSON Schema to enforce intent (integer vs decimal-as-string, fixed scale, ranges) for producers and consumers.
• If you must accept numbers, constrain them with JSON Schema (for example, use multipleOf to express decimal steps, while checking the validator’s handling of numeric precision), and test round-trip behavior across your parser set.

JSON Schema examples

1) Integer digits as a string (an optional leading minus is allowed; no plus sign or spaces):

{
  "type": "string",
  "pattern": "^-?[0-9]+$"
}

2) Decimal amount with two fraction digits as a string:

{
  "type": "string",
  "pattern": "^-?[0-9]+(\\.[0-9]{2})$"
}

3) Decimal amount as a number with two-decimal increments:

{
  "type": "number",
  "multipleOf": 0.01
}

JSON Schema distinguishes validation intent (integer vs number) even though raw JSON just has numbers. Use integer when only whole values are allowed, and number when fractions are allowed JSON Schema numeric reference. See our explainer on What JSON Schema is used for in practice.

Decide how to handle large and precise numbers in JSON

• Identify fields that require exactness (IDs, money, precise measurements) and choose string serialization for them.
• Define JSON Schema for each numeric field (use integer, number with multipleOf, or string with a validating pattern).
• Round-trip test samples across your target parsers and languages, including boundary integers near 9007199254740991 and long decimals.
• Reject NaN/Infinity during validation; they are not valid JSON numbers.
• Document any parser settings (for example, high-precision modes) that API consumers must enable.

Short FAQ

Are 1 and 1.0 different in JSON?
No. They are both JSON numbers; JSON does not define separate integer and float types. Runtimes may store or print them differently RFC 8259, RFC 8259.

What range of integers is generally safe?
With widely used binary64 implementations, integers in [-9007199254740991, 9007199254740991] are interoperably exact RFC 8259.

Can I send Infinity or NaN?
No. The JSON grammar does not permit them RFC 8259.

Related reading: Why comments are not permitted in JSON.