JSON Validator

A data handoff succeeds only when the receiver reads the same value the sender intended. Strict JSON provides a small, portable syntax for objects, arrays, strings, numbers, booleans, and null. Configuration formats such as JSON with Comments (JSONC) and JSON5 add conveniences for people, while JSON Lines stores a separate JSON value on each nonblank line.

Those formats look related but are not interchangeable by default. Comments, trailing commas, single-quoted strings, unquoted keys, hexadecimal numbers, NaN, and Infinity may be accepted in one mode and rejected by a strict API. Converting accepted input to strict JSON can also change representation, so the normalized copy needs review rather than blind replacement.

Syntax validity

The selected grammar can parse the complete source.

Interoperability

Different receivers are likely to agree on member names and numeric meaning.

Contract validity

The parsed value also has the fields and business rules required by a particular application or schema.

Repeated object names are a classic interoperability risk. Some parsers keep the last value, some preserve every occurrence, and others reject the object. Large integers create a different problem: text can preserve every digit while a JavaScript-style number cannot represent an integer exactly outside the safe range from −(2⁵³ − 1) to 2⁵³ − 1.

A primitive such as true or 42 is valid JSON, even though many APIs expect a top-level object or array. Syntax validation therefore answers a narrower question than JSON Schema, an API contract, or a package manifest specification. The receiving system remains the authority for required properties, value ranges, and domain meaning.

Formatting is useful after validation, not before it. Pretty indentation can make a document easier to inspect, compact output can reduce whitespace, and sorted keys can make comparisons steadier, but none of those presentation choices repairs a duplicate member or proves that a payload satisfies its destination.

How to Use This Tool:

Select the grammar and receiving shape before treating a formatted copy as portable JSON.

1. Paste or load the JSON source, then choose Input mode. Use automatic detection when the format is unknown, or select the exact grammar when the destination already defines it.
2. Choose a Review profile. Generic review stays format-focused; API object, array payload, and package manifest profiles add small post-parse shape checks.
3. Set the Duplicate keys and Unsafe numbers policies. Use error mode when either condition must block handoff, and warning mode when a person will review the result.
4. Read the first parser error or the Issue ledger. Copy the Normalized artifact only after its mode, duplicate rows, number warnings, and root-shape result match the receiving system.

Interpreting Results:

Valid JSON means parsing and the selected review policy produced no errors or warnings. Valid with notes means the source parsed, but normalization or a warning-level condition needs attention. A syntax, duplicate-key, precision, or profile result names the reason the handoff is blocked under the chosen policies.

Fix a syntax error first because later structure metrics and normalized output depend on a complete parse. After syntax succeeds, inspect repeated keys and unsafe numbers before trusting a clean-looking artifact. The resolved mode matters in automatic detection because it tells you which grammar actually accepted the text.

A passing profile is intentionally modest. It can confirm a top-level object, a nonempty array, or a few package-manifest fields, but it does not validate a product schema, an OpenAPI definition, or application-specific semantics.

Technical Details:

The source is parsed into one canonical value before structure counts, policy findings, and normalized output are produced. Objects contribute member counts, arrays contribute item counts, and every value including the root contributes one node. Maximum depth begins at 1 for the root.

Transformation Core

Each input mode has a distinct path from source text to strict JSON output.

Automatic detection uses a fixed order. It tries strict JSON first, then JSON Lines when at least two nonblank lines each parse independently, then JSONC when comments or trailing commas were actually consumed, and finally JSON5. If none succeeds, strict mode supplies the parser error. This order makes the same input resolve consistently.

Rule Core

Pretty output uses the selected indent from 0 to 8 spaces. Compact output ignores indentation. Canonical key order recursively sorts object keys while preserving array order; it is useful for comparison but is not a cryptographic canonicalization standard.

Accuracy and Privacy Notes:

Text and selected files are processed in the browser and are not sent to a validation service. Input is limited to 2 MiB.

• Accepted JSONC and JSON5 behavior is the behavior documented here, not a promise to emulate every parser or extension.
• Duplicate-member evidence is preserved even though the parsed value itself keeps the later value.
• Number warnings reflect JavaScript number precision. A receiver using decimal or arbitrary-precision types may behave differently.
• Normalization can remove comments, trailing commas, original spacing, and original key order. Keep the source when those editorial details matter.

Worked Examples:

References:

• RFC 8259: The JavaScript Object Notation Data Interchange Format, RFC Editor, December 2017.
• ECMA-404: The JSON Data Interchange Syntax, Ecma International, December 2017.
• The JSON5 Data Interchange Format, JSON5.
• JSONC Specification, JSONC.