JSON to JSON Schema, with the guesses spelled out

No — inference describes the document you pasted, and a schema describes a contract, which is strictly more information than any single document contains. Three things in particular cannot be observed: whether a key that happens to be present is ever absent, whether the four values a status field took here are the only four it can take, and what belongs in an array that arrived empty. A generated schema is therefore a first draft that removes the tedious 90% — the nesting, the types, the property names — and leaves you the decisions. Every one of those decisions is listed under the result rather than buried in the output.

It means the key must be present, and nothing more. A property listed in required with type "string" is satisfied by "" and violated by the key being missing; a null fails on the type, not on required, and only if null is absent from the type. That is why a field the sample only ever saw as null is typed "null" here and flagged for you to widen — ['string', 'null'] is almost always what was meant. Required also says nothing about order, and JSON Schema has no way to require ordering of object keys at all.

By default it is a label. Draft 2020-12 splits format into two vocabularies, and the one in the standard dialect is Format-Annotation: a validator that supports it will note the format and still pass a value of "not-an-email". Assertion behaviour is opt-in — Ajv needs the ajv-formats package added, Python's jsonschema needs the format checker passed in explicitly. So the format keywords this generator writes are documentation until you switch assertion on, which is worth knowing before you rely on one to reject bad input.

It depends on which direction you are protecting. Closing an object catches typos in config keys — a misspelled retryLimit is silently ignored by an open schema and rejected by a closed one — so it is the right default for anything a human hand-writes. For an API response it usually is not: a service that adds a field in a minor release will break every client validating with a closed schema, which is why most public API schemas stay open on purpose. It also composes badly: close an object and then combine it through allOf and the result rejects the very keys the other branch introduced, because the keyword is evaluated against its own siblings alone.

Draft 2020-12, declared by the $schema line at the top. It is the current release and what Ajv understands through its 2020 build, what python-jsonschema supports as Draft202012Validator, and what OpenAPI 3.1 aligned itself with. If your tooling is on draft-07 you need three edits: 2020-12 renamed definitions to $defs, replaced the array form of items with prefixItems and gave items the job of describing every remaining element, and split dependencies into dependentRequired and dependentSchemas. Nothing else in a schema this shape changes.

Because integer is used only when no fractional value turned up in the sample. A quantity that reads 2, 1 and 6 becomes integer; the moment one record carries 1.5 the whole property becomes number, since a value validated against integer must have a zero fractional part. That is worth checking against reality rather than against your payload — a unit price that happened to be a round 18 in every sampled record will be typed integer and will then reject 18.50 in production. The switch in the toolbar turns the distinction off and types every number as number.

Enough that optional fields have a chance to go missing — in practice twenty to a few hundred records of the same shape. Every element of an array is folded into one items schema, so the union of properties grows and the intersection that becomes required shrinks as you add records; with a single object the two are identical and everything looks mandatory. Beyond a few hundred the schema stops changing, and the 5 MB ceiling is far more than a representative sample ever needs.