JSON Validator
{{ summaryFigure }}
{{ summaryDetail }}
{{ statusBadge }} Root {{ rootTypeLabel }} {{ formatCount(metrics.nodeCount) }} nodes Duplicates {{ duplicateCount }} {{ warningCount }} note(s)
Paste one JSON value or browse/drop a .json or .txt file.
{{ fileMeta || sourceMetaLabel }}
Drop JSON or TXT onto the textarea.
Choose whether repeated object member names are reported as warnings or interoperability errors.
Use 0 to 8 spaces; validation itself is not affected.
spaces
Area Metric Value Evidence Copy
{{ row.area }} {{ row.metric }} {{ row.value }} {{ row.evidence }}
Severity Issue Location Evidence Recommended action Copy
{{ row.severity }} {{ row.issue }} {{ row.location }} {{ row.evidence }} {{ row.action }}
Tags: Data Format, Devtools, Text
Export to PDF Fullscreen
Customize
Advanced
:

JSON is a compact data format for moving structured values between systems. A payload can look tidy at a glance and still fail because one comma is missing, a string is not closed, a number is too large for the receiving runtime, or the same object key appears twice with different values.

Validation answers a narrow but important question before an API request, configuration handoff, fixture update, webhook test, or log sample leaves the editor. It checks whether the text is one valid JSON value, then helps explain what the parser accepted and what a reviewer should inspect next.

JSON source passing through syntax parsing, duplicate key review, and result evidence

JSON validation does not prove that a payload matches a product schema, an OpenAPI contract, or a business rule. It proves the text can be parsed as JSON and highlights common interchange risks that can make two systems interpret the same text differently.

Duplicate keys deserve special attention. Some parsers keep the last value, some reject the object, and some expose all entries. A validator that reports repeated names gives reviewers a chance to fix ambiguity before the receiving service decides for them.

Technical Details:

A JSON text is one serialized value. That value can be an object, array, string, number, boolean, or null, with insignificant whitespace allowed around structural characters. JSON does not allow comments, trailing commas, unquoted object names, single-quoted strings, NaN, or Infinity.

Objects are collections of name and value pairs, and arrays are ordered sequences of values. Object names should be unique for reliable interchange. When names repeat inside the same object, syntax may still parse, but downstream behavior is no longer predictable across implementations.

Rule Core

The validation path separates syntax failure from review warnings. That distinction matters because a syntax error blocks parsing, while duplicate keys and unsafe numbers can still leave a parseable value that deserves review.

Stage Rule Result Signal
Source present Validation waits until the source editor contains non-whitespace text. Waiting for JSON with input size evidence.
Syntax parse The source must parse as one JSON value using the browser's JSON parser. Syntax error with message, line, and column when available.
Duplicate scan Object keys are scanned within each object path after syntax parsing succeeds. Warning, Error, or Info based on the duplicate-key policy.
Number review Parsed integers outside JavaScript safe-integer precision are listed as risks. Number precision risk rows in the issue ledger.
Structure walk The parsed value is traversed to count values, keys, array items, depth, types, and size. Validation Report rows and Structure Footprint counts.

Accepted JSON Values

Value Type Valid Root? Review Note
Object Yes Most API payloads use an object root; repeated member names are checked per object.
Array Yes Array order is preserved and each item contributes to node and type counts.
String, number, boolean, or null Yes Primitive roots are valid JSON, but some receiving APIs require an object or array.

Formatted output is a re-serialization of the parsed value. The indent setting changes only the emitted text shape, from compact output at 0 spaces to a maximum of 8 spaces. It does not repair schema problems or preserve duplicate object members that the parser has already collapsed into one property value.

Large integers need a separate review cue because JSON's number grammar is broader than JavaScript's exact integer range. In this browser workflow, integers greater than 9007199254740991 or less than -9007199254740991 can lose exact digit identity after parsing, so identifiers and account-like numbers are often safer as strings.

Everyday Use & Decision Guide:

Start with Warn on duplicate keys for API payload review. It keeps valid syntax separate from interoperability warnings, so a payload can show Valid with notes while still pointing to the repeated key that should be fixed before handoff.

Switch to Treat duplicates as errors when the receiving service, contract review, or release checklist requires unique object member names. Use Ignore duplicate keys only when you are checking syntax for a controlled sample and already know repeated names are irrelevant to the next step.

  • Paste into JSON source for quick checks, or use Browse JSON / drag and drop for a local JSON or text file.
  • Use Sample when you want to see the status badges, report rows, issue rows, formatted view, and footprint chart without preparing input.
  • Set Formatted output indent to 2 spaces for readable review, 4 spaces for teams that prefer wider nesting, or 0 spaces for compact output.
  • Check Issue Ledger before copying formatted text. A parseable payload can still contain duplicate keys, unsafe integers, or a primitive root that the target API may reject.

Selected files are read into the browser editor and validated in the page workflow. That is useful for sensitive snippets because the source-processing path shown here does not make a backend validation request.

Do not treat Valid JSON as schema approval. After syntax and interoperability notes are clear, run the payload through the receiving API, schema checker, contract test, or configuration validator that knows the required fields and allowed values.

Step-by-Step Guide:

Use the source editor, duplicate-key setting, summary badges, and result tabs as checkpoints while moving from raw JSON to a reviewed payload.

  1. Paste JSON into JSON source, choose Browse JSON, drop a JSON or text file onto the textarea, or load Sample to populate a known valid payload.
  2. Choose Duplicate key handling. Keep Warn on duplicate keys for general review, or select Treat duplicates as errors when repeated names should block handoff.
  3. Open Advanced if formatted text matters, then set Formatted output indent from 0 to 8 spaces. This setting affects only Formatted JSON.
  4. Read the summary status. Syntax error means the parser stopped; fix the reported message and line or column before using any formatted output.
  5. Open Validation Report for root type, node count, maximum depth, key and array counts, input size, formatted size, duplicate count, unsafe-number count, and parse time.
  6. Open Issue Ledger for the exact severity, issue, location, evidence, and recommended action. Duplicate keys report the repeated key path and both occurrence locations when available.
  7. Use Formatted JSON only after syntax succeeds. If the tab is not visible, the source has not parsed successfully.
  8. Use Structure Footprint to compare object, array, string, number, boolean, and null counts, then open JSON for a structured diagnostic summary when you need to share evidence.

After the report and issue rows match expectations, copy or download the output that fits the review handoff.

Interpreting Results:

Valid JSON means syntax parsing succeeded and no duplicate-key or unsafe-number notes were found. Valid with notes means the value parsed but at least one review issue deserves attention. Interop error means the duplicate policy has elevated repeated keys from warning to failure.

Root type matters because JSON allows primitive roots even when many APIs expect an object or array. A root of string, number, boolean, or null should be checked against the receiving contract before use.

Use Maximum depth, Node count, Object keys, and Array items as review signals, not quality scores. A large or deeply nested payload is not wrong by itself, but it is harder to inspect and more likely to hide a misplaced array item or object member.

The strongest false-confidence warning is duplicate keys. Formatted output can look clean after parsing, while the original text still contained two values for the same name. Trust the Issue Ledger location evidence before trusting the formatted copy.

Worked Examples:

API request body check

A payload such as {"service":"billing-api","active":true,"limits":{"rpm":1200,"burst":250}} should return Valid JSON, an object Root type, node and key counts in Validation Report, and no issue rows beyond a pass entry. The formatted output is suitable for a pull request comment or API client body after the endpoint contract is checked separately.

Repeated member before release review

{"role":"viewer","role":"admin","enabled":true} parses, but Issue Ledger reports Duplicate key at the root path. With Warn on duplicate keys, the summary becomes Valid with notes; with Treat duplicates as errors, it becomes Interop error. Remove or rename the repeated member before handoff.

Large identifier stored as a number

{"invoice_id":9007199254740993} can parse while still showing Number precision risk. The safer payload for an exact identifier is {"invoice_id":"9007199254740993"}, then the issue ledger should no longer report the unsafe integer at $.invoice_id.

Trailing comma troubleshooting

{"name":"staging",} should stop with Syntax error. Start at the reported location, remove the trailing comma after the last member, and check that Formatted JSON appears after the next parse.

FAQ:

Does valid JSON mean my API will accept it?

No. Syntax success means the source parses as JSON. The receiving API can still reject missing fields, wrong field names, unsupported enum values, primitive roots, or values that violate a schema.

Why are comments and trailing commas rejected?

The validator checks JSON, not JSONC or JavaScript object literal syntax. Comments, trailing commas, unquoted keys, and single-quoted strings remain syntax errors.

What should I do with duplicate keys?

Treat them as ambiguous data. The issue row gives the repeated key path and occurrence locations, so remove one value or rename the member before sending the payload to another system.

Why does a big number show a precision warning?

The browser parses JSON numbers into JavaScript numbers. Integers outside the safe range can lose exactness, so account numbers, IDs, and other exact digit strings should usually be quoted.

Are selected files sent away for validation?

Selected JSON and text files are read into the browser editor and checked by the page workflow. The source-processing path used here does not make a backend validation request.

Glossary:

Array
An ordered JSON sequence written with square brackets.
Duplicate key
A repeated object member name within the same object path.
Interoperability
The chance that different parsers and receiving systems agree on the same name and value mappings.
Node count
The total count of JSON values found while walking the parsed value, including the root.
Object
A JSON value written with curly braces and made of name and value pairs.
Primitive root
A valid JSON root that is a string, number, boolean, or null instead of an object or array.
Safe integer
An integer that JavaScript can represent exactly as a number without sharing that value with a neighboring integer.

References: