JSONKit
3 / 6

Lesson 3: Numbers & Ranges

Schema Editor
Data Editor
Validation Result

Type in the editors to see validation results.

minimummaximumexclusiveMinimummultipleOfinteger

The "minimum" and "maximum" keywords set inclusive bounds — the value must be greater than or equal to minimum and less than or equal to maximum. "exclusiveMinimum" and "exclusiveMaximum" enforce strict bounds where the boundary value itself is not allowed. The "multipleOf" keyword requires the number to be evenly divisible by the specified value, which is useful for enforcing step sizes like multiples of 5. To restrict a field to whole numbers only, use "type": "integer" instead of "type": "number".

Why This Matters

Numeric fields silently accepting the wrong range is one of the most common sources of production bugs — negative quantities, discounts over 100%, or page sizes of zero all tend to slip past code that only checks "is this a number?" Bounds and divisibility constraints push that validation to the edge of your system, where a bad request gets rejected with a clear message instead of corrupting a database row or crashing a downstream calculation. "multipleOf" is also the standard way to model discrete steps — page sizes in multiples of 10, prices in whole cents, or time slots in 15-minute increments.

Common Mistakes

  • ✕ Writing Draft-04-style boolean exclusiveMinimum, like "minimum": 0, "exclusiveMinimum": true.In Draft 2020-12 (and Draft 6+), "exclusiveMinimum" is a number, used on its own: "exclusiveMinimum": 0 — not a boolean modifier on "minimum". Mixing the old and new syntax silently produces the wrong constraint.
  • ✕ Using "minimum": 0 when the intent is "must be positive, zero not allowed"."minimum": 0 allows zero. Use "exclusiveMinimum": 0 to require a strictly positive number.
  • ✕ Relying on "multipleOf" with values that have floating-point precision issues, like 0.1 or 0.3.Because binary floating point can't represent every decimal exactly, some validators report false negatives for values like multipleOf: 0.1 against 3.0. For money, prefer validating whole cents as integers (multipleOf: 1 on a cents field) rather than fractional dollars.
  • ✕ Using "type": "number" for a field that should never be fractional, like a quantity or an ID.Use "type": "integer" so a value like 5.5 is rejected outright, instead of relying on application code to round or floor it later.

Challenge

Set discountPercent to 7 (not a multiple of 5) and observe the error.

Frequently Asked Questions

"minimum" is inclusive — the value can equal the bound. "exclusiveMinimum" (and "exclusiveMaximum") is strict — the value must be greater than (or less than) the bound, never equal to it.

Yes, but be aware of floating-point rounding: values like 0.01 or 0.1 aren't always exactly representable in binary floating point, which can occasionally cause a mathematically-valid multiple to fail. For currency, validating integer cents is more reliable than fractional dollar amounts.

Combine "type": "integer" with "exclusiveMinimum": 0. Using "minimum": 1 also works and is equivalent for integers, since there's no integer strictly between 0 and 1.

Not natively — JSON's number type is a double-precision float, so JSON Schema validates numeric ranges and multiples but can't guarantee decimal-exact arithmetic. Most production systems store money as integer minor units (cents) precisely to sidestep this.