Generate a JSON Schema from a document and see whether it actually validates that document, with every number written back exactly as the file spelled it and formats checked against the calendar and the clock rather than by pattern
Initializing in your browser…
Format, validate and minify JSON, JSON with comments and JSON5, without changing a single value: every number is written back as the document spelled it. Errors carry a line, a column and the offending line. JSONPath queries, tree view, schema checks and diff
Haiku in nine themes, with every line counted after it is built from CMU Pronouncing Dictionary syllable counts rather than a spelling rule, and a seed in the link so a poem can be shared
Build or paste a Markdown table and see it read back cell by cell, with column widths measured in display columns so CJK text, emoji and accents line up, and pipes escaped in the right order
An order payload holds a 20 digit order number and two line items, and only one of them has a note field.
Document
{"orderId": 12345678901234567890, "lines": [{"sku":"A-1","note":"gift"},{"sku":"B-7"}]}Schema
orderId: integer. lines: array of objects with sku required and note optional. Your document validates against this schema.
Every sample of a property is folded together, so note is optional rather than required and the schema accepts the document it came from; the page says so rather than leaving you to find out. The order number is written back with all twenty digits, because the document is read without turning any number into a double.
Paste a JSON document and get a JSON Schema inferred from it, then see whether that schema actually accepts the document it came from. That check is the whole point: a schema generator makes exactly one claim, and it is a claim you can test. Every value the schema quotes back is written exactly as your file spelled it, so a 20 digit identifier stays 20 digits.
A generated schema is a guess made from evidence, and the evidence is one document. This tool is built around being honest about that in two specific ways.
First, it folds ALL the evidence rather than the first piece of it. An array holding an integer and a fraction is an array of numbers, not an array of integers; a property whose first sample is null and whose second is a number allows both. Getting that wrong produces a schema that refuses the document it was generated from, which is the one thing a generated schema must never do. Every property, at every depth, is described by every value it was ever seen holding: the types union, the sub-schemas merge property by property, and "required" is by default the intersection, meaning only the properties every sample actually had. You can override that, and if you ask for every property to be required when the samples disagree, the page tells you the resulting schema no longer accepts your document.
Second, it does not round your numbers. The document is read by a parser that carries every number as its exact source token rather than as a double, so `12345678901234567890` stays itself instead of becoming `12345678901234567000`, `19.90` stays `19.90` instead of `19.9`, `1e3` stays `1e3`, and thirty significant digits stay thirty. Wherever the schema quotes a value back (in an example, in an enum, in a minimum or a maximum) it writes the token your file held. The page names any number a double-based reader would change.
String formats are checked rather than pattern matched. A date is checked against the calendar, so 2024-02-30 is not a date and 2024-02-29 is. A time is checked against the clock, so 25:00:00 is not a time and the 23:59:60 leap second is. An IPv4 address has four octets each at most 255, an IPv6 address follows RFC 4291 including the compressed form, an e-mail address follows the WHATWG HTML production, and a URI needs a scheme and well formed percent-encoding. A format is an annotation in both drafts by default, so a format that is wrong never makes a document invalid, only the schema untrue.
What it does not do is invent constraints. Minimum, maximum, minLength and maxLength are off by default and, when turned on, come from the values in your document and say so. additionalProperties: false is off by default, because refusing a field you have not seen will reject the next version of the same file. And the tool states which JSON Schema keywords it can emit, which is the same list its own checker understands, so there is nothing it quietly skips.
Generate a schema from a sample response and check it accepts that response before you commit it, so a schema that would reject your own payload never reaches CI.
Generate a schema for a config file, with additionalProperties left open so a new option does not fail the check the day it is added.
Order numbers, Twitter-style snowflake ids and precise decimal prices survive intact, and the page names any value a JSON.parse based tool would have changed.
The schema is a compact description of a document, including which properties every record has and which only some do.
That is the first thing the page tells you, and with the default settings the answer is yes. It is checked here against every keyword the tool can emit, and independently against Python's jsonschema in this project's tests: 20 of 20 corpus documents validate against their own schema, where the previous version managed 18.
Because most of them read JSON with a function that turns every number into a 64-bit float, which holds about 15 to 17 significant digits. RFC 8259 section 6 sets no limit on the digits in a JSON number and only recommends that range for interoperability. This tool keeps the exact text and names any number that a double would change.
Draft-07 is the most widely supported; 2020-12 is the current one and is what OpenAPI 3.1 uses. The choice changes the $schema your document declares. The keywords this tool emits mean the same thing in both.
Because one document cannot establish that a field will never appear. Turning it on writes additionalProperties: false, and the option says what that costs.
No, and it does not pretend to. It emits a fixed list of keywords, shown in the Options panel, and its own checker understands exactly that list. Anything else you want in the schema is yours to add after copying it.
No. The document is parsed, the schema is generated and the check is run entirely in your browser.
Your text is processed locally in the browser. Nothing you paste or open is transmitted or logged.