The two names get used interchangeably, and many sites put both on one page. They answer different questions. A formatter answers "can I read this?" A validator answers "is this JSON at all?" Neither answers the question that usually matters in production, "is this the JSON my code expects?", which is schema validation, a third job.
On DevPrix, the JSON formatter and the JSON validator run the same engine. Both parse as you type, both point at errors by line and column, and both can pretty-print, minify or show a tree. Use whichever page matches the job; the result is identical, and nothing you paste is uploaded.
What a formatter changes
Formatting rewrites insignificant whitespace: the spaces, tabs and newlines between tokens. Here is a minified webhook body:
{"id":"evt_01JB8Z3K","type":"deployment.succeeded","project":{"name":"devprix-tools","region":"bom1"},"tags":["production","next"],"commit":null}And the same document with 2-space indentation:
{
"id": "evt_01JB8Z3K",
"type": "deployment.succeeded",
"project": {
"name": "devprix-tools",
"region": "bom1"
},
"tags": [
"production",
"next"
],
"commit": null
}The formatter offers 2 spaces, 4 spaces or tabs; a Minified view that strips all whitespace; a Tree view where every object and array collapses and shows how many entries it holds; and Sort keys, which sorts object keys at every level while arrays keep their order. The status bar shows the size before and after, a quick way to see what minifying saves.
One consequence is easy to miss: a formatter has to parse before it can print, so it cannot format broken JSON. Every formatter that parses is also a syntax validator.
Formatting can change more than whitespace
Browser-based formatters, this one included, parse the text with JSON.parse and print it again with JSON.stringify. The output is the same data for most purposes, but not always the same bytes. Feed it this:
{"b": 1, "id": 9007199254740993, "price": 1.50, "limit": 1e3,
"name": "caf\u00e9", "url": "https:\/\/x.io",
"role": "user", "role": "admin", "10": "ten", "2": "two"}And you get this back:
{
"2": "two",
"10": "ten",
"b": 1,
"id": 9007199254740992,
"price": 1.5,
"limit": 1000,
"name": "café",
"url": "https://x.io",
"role": "admin"
}- Numbers are reprinted in their shortest form.
1.50becomes1.5and1e3becomes1000. Same value, different text. - Escapes are decoded.
\u00e9becomeséand\/becomes/. Again, the same string. - Duplicate keys collapse. RFC 8259 says object names should be unique and that software receiving duplicates behaves unpredictably.
JSON.parsekeeps the last value, so"role": "user"silently disappears. A syntax validator calls the input valid, because it is. - Integer-like keys move to the front. JavaScript objects put keys such as
"2"and"10"first, in numeric order, whatever order the input used. - Large integers lose precision. JavaScript numbers are IEEE 754 doubles, exact only up to 9007199254740991 (2^53 − 1), so
9007199254740993becomes9007199254740992without warning. RFC 8259 calls out this interoperability limit.
None of this matters when you are reading a response. It matters when you paste formatted output back over the original. Watch two cases in particular: IDs above 2^53, which should travel as strings, and signed payloads. A webhook signature is computed over the exact bytes that were sent, so verify it against the raw request body, never against a reformatted copy.
What a validator checks
A JSON validator checks syntax against RFC 8259: one root value, double-quoted strings and keys, legal escapes, commas in the right places, no comments, numbers without leading zeros, and only true, false and null as literals. The answer is binary: valid, or invalid at a specific line and column. When it is invalid, the guide to common JSON syntax errors explains what each message means and how to fix it.
Syntax is all it checks. Each of these is valid JSON:
{"port": "8080", "replicas": -3, "enabled": "false"}"null"42The first stores a port as a string, an impossible replica count and a boolean as text. The second is a string that happens to contain the word null. The third is a bare number, which RFC 8259 allows as a complete JSON text. A validator accepts all three, and your service may still fall over.
Schema validation is a third job
To check shape (types, required fields, allowed values, ranges) you need a schema, and JSON Schema is the common standard. A schema for the config above might be:
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"required": ["port", "replicas"],
"properties": {
"port": { "type": "integer", "minimum": 1, "maximum": 65535 },
"replicas": { "type": "integer", "minimum": 1 },
"enabled": { "type": "boolean" }
}
}Checked against it, the document fails three times: port is a string, replicas is below its minimum, and enabled is a string. To be clear about scope: DevPrix does not validate JSON against a schema. It can give you a starting point. The JSON to TypeScript converter has a JSON Schema output that infers types and required keys from a sample; ranges, enums and most formats are yours to add. Then run the schema with a validator library, such as Ajv in JavaScript or jsonschema in Python, in tests or CI. In TypeScript, a runtime validator such as Zod covers the same ground in code; converting JSON to TypeScript safely walks through that route.
Which one to use
- A parse error in your logs or a client: the validator, to find the exact line and column.
- A minified response you need to read: the formatter, in Formatted or Tree view.
- A payload for a curl command, an environment variable or a single log line: Minified.
- Two documents to compare: Sort keys on both helps a text diff, but a structural JSON diff ignores key order on its own.
- A payload that parses but breaks your API: a schema validator or runtime validation in code, not a formatter.
Next steps
Paste your document into the JSON formatter. If it reports valid JSON and your service still rejects it, you have a shape problem and need a schema. If you are about to send the formatted result to someone, read how to format JSON safely before sharing it first.