type : String | Array<String>
type
String | Array<String>Validation succeeds if the type of the instance matches the type represented by the given type, or matches at least one of the given types.
| Value |
This keyword must be set to either a string that corresponds to one of the supported types, or a non-empty array of unique strings that correspond to one of the supported types
Hint: Use the jsonschema metaschema command to catch keywords set to invalid values
|
|---|---|
| Kind | Assertion |
| Applies To | Any |
| Base Dialect | 2020-12 |
| Changed In | Draft 6 Draft 4 |
| Introduced In | Draft 1 |
| Vocabulary | Validation |
| Specification | https://json-schema.org/draft/2020-12/json-schema-validation.html#section-6.1.1 |
| Metaschema | https://json-schema.org/draft/2020-12/meta/validation |
| Official Tests | draft2020-12/type.json |
| Default |
[ "null", "boolean", "object", "array", "number", "string" ]
|
| Annotation | None |
| Affected By | None |
| Affects | None |
The supported types are the following. Note that while the ECMA 404 JSON standard defines the JSON grammar without mention of encodings, the IETF RFC 8259 JSON standard provides specific guidance for JSON numbers and JSON strings which are documented in the Interoperable Encoding column. Other encodings will likely not be accepted by JSON parsers.
| Type | Description | Interoperable Encoding |
|---|---|---|
"null" |
The JSON null constant | N/A |
"boolean" |
The JSON true or false constants | N/A |
"object" |
A JSON object | N/A |
"array" |
A JSON array | N/A |
"number" |
A JSON number | IEEE 764 64-bit double-precision floating point encoding (except NaN, Infinity, and +0) |
"integer" |
A JSON number that represents an integer | 64-bit signed integer encoding (from -(2^53)+1 to (2^53)-1) |
"string" |
A JSON string | UTF-8 Unicode encoding |
Note that while the JSON grammar does not distinguish between integer and real
numbers, JSON Schema provides the integer logical type that matches either
integers (such as 2), or real numbers where the fractional part is zero (such
as 2.0). Additionally, numeric constructs inherent to floating point
encodings (like NaN and Infinity) are not permitted in JSON. However, the
negative zero (-0) is permitted.
Best Practice
To avoid interoperability issues, do not produce JSON documents with numbers that exceed the IETF RFC 8259 limits described in the Interoperable Encodings column of the table above.
If more numeric precision is required, consider representing numbers as JSON strings or as multiple numbers. For example, fixed-precision real numbers can be represented as an array of two integers for the integral and fractional components.
Common Pitfall
The JavaScript programming language (and by extension languages such as TypeScript) represent all numbers, including integers, using the IEEE 764 floating-point encoding. As a result, parsing JSON documents with integers beyond the 53-bit range is prone to precision problems. Read How numbers are encoded in JavaScript by Dr. Axel Rauschmayer for a more detailed overview of JavaScript’s numeric limitations.
Digging Deeper
JSON allows numbers to be represented in scientific
expontential
notation. For
example, numbers like 1.0e+28 (equivalent to 10000000000000000000000000000.0)
are valid according to the JSON grammar. This notation is convenient for
expressing long numbers. However, be careful with not accidentally exceeding
the interoperable limits described by the IETF RFC
8259 JSON
standard.
Examples
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "number"
}423.141.0e+28"foo"{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": [ "boolean", "array" ]
}true1234[ 1, 2, 3 ]{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "integer"
}423.03.14