JSON Schema Validator
Work with JSON data more effectively using this json schema validator. Validate, format, and manipulate JSON with ease.
Features
- Syntax Validation: Catch JSON errors instantly
- Pretty Printing: Format JSON for readability
- Minification: Compress JSON for production
- Path Navigation: Find and extract specific values
Example
Input:
``
// Validate JSON against a JSON Schema
`
Output:
`
✓ Valid JSON
✗ Error: "age" must be integer
`
Tips
Supports JSON Schema Draft 7- Shows all validation errors
- Validates types, required fields, patterns
How to Use
1. Paste your JSON in the input area
2. Click process to validate and format
3. Review the results
4. Copy or download the result
Best Practices
- Always validate JSON before using in production
- Use consistent indentation (2 or 4 spaces)
- Keep keys in a consistent order
- Remove unnecessary whitespace for APIs
JSON Schema
JSON Schema describes the shape a document must have, and is the standard way to validate
API payloads and configuration files.
`json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"required": ["id", "email"],
"properties": {
"id": { "type": "integer", "minimum": 1 },
"email": { "type": "string", "format": "email" },
"tags": { "type": "array", "items": { "type": "string" } }
},
"additionalProperties": false
}
`
Two things catch people out. additionalProperties: false is not the default — without it,
unexpected keys pass validation silently. And format is annotation-only in the
specification: many validators do not enforce format: "email" unless you turn it on.
Numbers Are the Recurring Problem
A JSON number is an IEEE 754 double. Three consequences that bite in production:
| Value | What happens |
|---|---|
| Integers above 2⁵³ | Silently lose precision — send IDs as strings |
| Money as a float | 0.1 + 0.2 = 0.30000000000000004 |
| Leading zeros | 007 is invalid JSON; "007" is a string |
NaN and Infinity | Not valid JSON at all |
Twitter hit the first one publicly: 64-bit tweet IDs arrived in JavaScript rounded, so the
API began sending an id_str alongside every id.Keys, Order and Duplicates
Objects are formally unordered, though every JavaScript engine preserves insertion order for
string keys — with one exception: integer-like keys sort numerically and come first.
`javascript
JSON.stringify({ b: 1, 2: 2, a: 3 }); // {"2":2,"b":1,"a":3}
`
Duplicate keys are not an error in the spec, and JSON.parse keeps the last one. Two
parsers can legitimately disagree about which value wins, which has been the basis of real
request-smuggling attacks.
Document and Schema
`json
{"id":1,"email":"ada@example.com"}
`
becomes
`json
{
"type": "object",
"required": ["id", "email"],
"properties": {
"id": { "type": "integer" },
"email": { "type": "string", "format": "email" }
}
}
`
An inferred schema is a starting point, not a specification — it cannot know which fields are optional, which strings are enums, or what the real bounds are.
Rules That Prevent Most JSON Bugs
| Rule | Why |
|---|---|
| No trailing commas | {"a": 1,} is invalid JSON, though JavaScript accepts it in object literals |
| Double quotes only | {'a': 1} is not JSON |
| Keys must be quoted | {a: 1} is a JavaScript object, not JSON |
| No comments | There is no comment syntax; JSON5 and JSONC are different formats |
No undefined, NaN, Infinity | JSON.stringify silently drops or nulls them |
| Numbers are IEEE 754 doubles | Integers above 2⁵³ lose precision — send them as strings |
Parsing Safely
`javascript
try {
const data = JSON.parse(text);
} catch (error) {
// The message names the character offset, which is the fastest way
// to find an unescaped quote in a large document.
console.error(error.message);
}
`
JSON.parse` throws on invalid input rather than returning null, so it always belongs in a try/catch when the source is a file, a request body or a clipboard paste.