Validation status
{{ summaryFigure }}
{{ summaryDetail }}
{{ statusBadge }} {{ parserProfileLabel }} Root {{ rootTypeLabel }} {{ contractProfileLabel }} {{ formatCount(metrics.nodeCount) }} nodes Duplicates {{ duplicateCount }} {{ warningCount }} note(s)
Choose the input dialect before validating so comments, trailing commas, and config syntax are handled intentionally.
Paste one JSON value or browse/drop a .json, .jsonc, .json5, or .txt file.
{{ fileMeta || sourceMetaLabel }}
{{ sourceActionHint }}
Use a workflow profile to flag root-shape and common handoff requirements.
Choose whether repeated object member names are reported as warnings or interoperability errors.
Set how unsafe integers and non-finite JSON5 numbers affect the validation result.
Choose whether the Formatted JSON tab is human-readable, compact, or key-sorted.
Use 0 to 8 spaces for pretty and canonical artifacts; compact output ignores this value.
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
YAML Validator Check YAML text or files in your browser, find parser errors and duplicate-key risks, then inspect document counts, paths, and parsed JSON.
JSON Formatter Turn messy JSON into readable, compact, sorted, or line-delimited output with duplicate-key, size, and number-precision warnings in your browser.
YAML Formatter Format YAML in your browser with parse warnings, path rows, change deltas, and JSON output before replacing configuration text.
JSON to CSV Converter Turn nested JSON or JSON Lines into spreadsheet-ready CSV or TSV, with record-path selection, flattened headers, previews, and formula warnings.
Customize
Advanced
:

JSON mistakes usually look small until another system has to read them. A trailing comma copied from a config file, a comment left in a sample payload, a repeated object member, or a large numeric identifier can turn a routine handoff into a parser error or a data mismatch. The text may still look like ordinary JavaScript object notation, but strict JSON uses a narrower grammar and many receivers report only a short invalid-payload message.

JSON is a data interchange syntax, not a schema language. It can represent objects, arrays, strings, numbers, booleans, and null, but it does not prove that an object has the fields an API expects, that every array item follows the same contract, or that a timestamp belongs to a real business rule. A useful validation pass therefore answers two separate questions: can the text be parsed as the intended JSON-like format, and does the parsed value carry risks that could change meaning during exchange?

Format Common use Main caution
Strict JSON API bodies, webhook samples, machine-readable exports, and portable fixtures. No comments, trailing commas, unquoted keys, single-quoted strings, NaN, or Infinity.
JSONC Human-edited configuration where comments help explain settings. Comments and trailing commas need deliberate cleanup before a strict JSON consumer reads the file.
JSON5 Configuration syntax that borrows more JavaScript-style conveniences. Accepted input can include features that disappear or change shape when emitted as strict JSON.
JSON Lines Logs, event streams, and record-by-record processing. Each non-blank line must be a complete JSON value; a blank line is not a record.
  • APIs and webhooks usually expect strict JSON, so comments and trailing commas need to be removed before the payload is sent.
  • Human-edited configuration may use JSONC or JSON5 conveniences, but those conveniences are not portable unless the target explicitly accepts them.
  • Logs and event streams often use JSON Lines, where each non-blank line is its own JSON value rather than one large array literal.
  • Syntax success does not settle duplicate names, unsafe integer precision, root-shape expectations, or product-specific schema rules.
JSON source passing through parser status and review checks for duplicate keys and precision risk.

Syntax success is the first checkpoint, not final approval. A payload can parse and still carry duplicate object names whose meaning changes by parser, an integer too large for exact JavaScript number handling, or a primitive root that is valid JSON but unsuitable for an API that expects an object. Those cases matter because different programs can accept the same text and then make different decisions from it.

The safest review habit is to match the source to the format it actually uses, fix hard syntax failures first, and then check the warnings before trusting a formatted copy. That keeps human-friendly configuration syntax separate from strict interchange data and prevents a pretty output from hiding an interoperability problem.

How to Use This Tool:

Start with the syntax choice, because the same pasted text can be invalid strict JSON but valid JSONC, JSON5, or JSON Lines.

  1. Set Parser profile to match the source: Strict JSON for API-safe payloads, JSONC config review for comments and trailing commas, JSON5 tolerant review for JSON5 syntax, or NDJSON / JSON Lines for one JSON value per line.
  2. Paste text into JSON source, select Browse JSON, drop a .json, .jsonc, .json5, or .txt file, or use Sample to load a profile-specific example. A selected file must be smaller than 2 MB.
  3. Choose a Review profile. Generic JSON value stays close to syntax and interoperability checks, while API object contract, Array payload contract, and package.json contract add root-shape or manifest checks after parsing succeeds.
    Use Generic JSON value when you only need grammar and interchange evidence. Use a contract profile when the receiving system expects a top-level object, array, or package manifest.
  4. Set Duplicate key handling and Number precision. Warning mode is useful for review, error mode is useful for a blocking handoff policy, and ignore or allow modes should be reserved for cases where the receiving system is already known.
  5. Use Advanced when the formatted artifact matters. Pretty JSON favors reading, Compact JSON removes unnecessary whitespace, and Canonical sorted JSON sorts object keys recursively for comparisons. Formatted output indent accepts 0 to 8 spaces.
  6. Read the summary and open Issue Ledger before copying output. Syntax error blocks formatted output; Valid with notes, Interop error, Precision error, or Contract error means the parsed value still needs review.
    Fix the first syntax error before trusting any formatted output. After parsing succeeds, clear duplicate-key and precision rows before sharing a strict JSON copy.

Interpreting Results:

Valid JSON means parsing succeeded and the selected review policies found no warning or blocking issue. It does not mean a product schema, API endpoint, package registry, or configuration loader will accept the payload.

Syntax error is the first problem to fix. Use the message, line, column, and source snippet when available, then recheck the source before paying attention to formatted output or structure counts.

Valid with notes means the value parsed but review evidence deserves attention. Comments removed from JSONC, trailing comma cleanup, JSON5 conversion, duplicate keys, unsafe numbers, primitive roots, and contract warnings are all examples of notes that can matter during a handoff.

The main false-confidence risk is a clean-looking formatted artifact after a duplicate key. A normal parser can keep only one value for the repeated name, so trust the Issue Ledger location evidence and fix the source before using the formatted copy.

Technical Details:

A JSON text serializes exactly one value. That value may be an object, array, string, number, boolean, or null. Objects are collections of string member names and values, while arrays are ordered value sequences. Strict JSON allows insignificant whitespace around punctuation, but it does not allow comments, trailing commas, unquoted member names, single-quoted strings, or non-finite numeric tokens.

Validation follows a rule-based process rather than a numeric formula. The important technical split is between parsing and review. Parsing decides whether the input grammar can produce a value. Review then checks interoperability risks that a parser alone may tolerate, such as repeated object member names, number precision, root shape, and structural size.

Transformation Core

The selected format changes how source text reaches the strict JSON artifact. Keeping that transformation visible prevents JSONC, JSON5, and JSON Lines from being mistaken for identical inputs.

Profile Accepted source pattern Transformation before output
Strict JSON One valid JSON value. The value is parsed directly, then re-serialized as pretty, compact, or recursively key-sorted JSON.
JSONC config review JSON with comments and trailing commas. Comments and trailing commas are replaced before strict parsing; cleanup counts appear in the report evidence.
JSON5 tolerant review JSON5 syntax such as comments, unquoted keys, single quotes, trailing commas, hexadecimal numbers, or non-finite numbers. The JSON5 value is parsed and emitted as strict JSON when the JSON5 parser is available; duplicate-key scanning can be limited for syntax outside strict JSON.
NDJSON / JSON Lines One JSON value per non-blank line. Each line is parsed independently and wrapped into one strict JSON array for formatted output.

Rule Core

The status labels come from ordered checks. A parse failure stops the value walk. A parse success unlocks structure metrics, issue rows, formatted output, and the type footprint chart.

Stage Rule Result signal
Source presence At least one non-whitespace character is required. Waiting for JSON and source-size rows.
Syntax parse The chosen format must produce one parsed value. Syntax error with message, line, column, and snippet when available.
Duplicate keys Repeated member names in the same object are recorded by path and occurrence location when scanning succeeds. Valid with notes, Interop error, or informational evidence based on the duplicate policy.
Number precision Unsafe integers and non-finite parsed numbers are listed. Precision error when the policy blocks, or warning and info rows when it does not.
Review profile Optional root-shape checks run after parse success. Contract error for blocking mismatches, with warning rows for softer concerns.
Structure walk The parsed value is counted by root type, nodes, depth, object keys, array items, strings, bytes, and parse time. Validation Report evidence and Structure Footprint chart data.

Duplicate member names are an interoperability risk because JSON standards recommend unique names but receiving software can differ when names repeat. Some parsers keep the last value, some fail, and some expose all occurrences. A repeated name should be treated as ambiguous until the source is corrected or the receiving system's behavior is known.

Number precision is separate from syntax. JSON can spell a large decimal integer, but a JavaScript number safely distinguishes only integers from -9007199254740991 through 9007199254740991. Values outside that safe range can lose exact digit identity after parsing, so identifiers, account numbers, order numbers, and invoice IDs should usually be strings.

Review profile Checks applied after parse Boundary to remember
Generic JSON value No extra root-shape requirement beyond parse and interoperability checks. A primitive root can be valid JSON even when a receiving API expects an object or array.
API object contract Requires a top-level object and warns when it is empty. It does not validate endpoint-specific required fields or allowed values.
Array payload contract Requires a top-level array, warns on an empty array, and warns when item types are mixed. It does not prove that every item follows the same schema.
package.json contract Requires a top-level object, non-empty name and version, and object-shaped dependency blocks. It is a lightweight manifest review, not a package-manager publish simulation.

A useful audit path is strict and repeatable: choose the intended source format, fix the first parser error, clear duplicate and precision risks, then compare root type, node count, maximum depth, and type footprint against what the receiving system expects. If two reviews need to be compared, keep the parser profile, review profile, duplicate policy, number policy, and formatting style unchanged.

Privacy Notes:

The validation workflow reads pasted text and selected files in the browser session. That is useful for sensitive drafts, but the safest habit is still to avoid pasting secrets unless the review itself requires them.

  • Selected files are loaded into the editor rather than uploaded for validation.
  • Generated reports, issue rows, diagnostic JSON, and formatted output can contain the same sensitive values as the source.
  • Do not share browser URLs, copied diagnostics, or exported reports when they include private tokens, customer data, or production credentials.

Advanced Tips:

  • Keep Duplicate key handling set to Warn on duplicate keys for exploratory review, then switch to Treat duplicates as errors when the payload is headed into a blocking release or partner handoff.
  • Use Treat precision risks as errors for payloads that contain account numbers, order IDs, invoice IDs, long Snowflake-style identifiers, or any number whose exact digits matter more than arithmetic.
  • Compare Structure Footprint with the expected root type, maximum depth, and type mix before accepting a large file. A valid parse can still reveal a primitive root or a mixed array that the receiver will reject.
  • Use Canonical sorted JSON only for stable comparison artifacts. It changes object key order in the output, so keep the original source when key order is meaningful to a human review.
  • For JSON Lines, check the reported line count against the event count you expected. A blank line is skipped, while one malformed non-blank line blocks the formatted array output.

Worked Examples:

API request body before a handoff

Set Parser profile to Strict JSON and use {"service":"billing","active":true,"limits":{"rpm":1200}}. The summary should show Valid JSON, Root object, and no issue rows. Validation Report gives node, key, depth, and byte counts, but the receiving API must still check the actual field contract.

Comments in a configuration draft

A source such as {"mode":"prod",// note "retry":3,} should use JSONC config review. The value can parse as Valid with notes, while Issue Ledger records normalization and Validation Report records removed comments or trailing commas. Copy Formatted JSON only after confirming that the target system wants strict JSON.

Repeated member name in a role payload

{"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 one member or rename the field before handoff.

JSON Lines event sample

For three event records on separate lines, set Parser profile to NDJSON / JSON Lines. Each non-blank line must parse on its own. Formatted JSON becomes one array, and Validation Report records the line count and node count so the output can be compared with a normal array payload.

Identifier that should not be numeric

{"invoice_id":9007199254740993} can parse while Issue Ledger reports Number precision risk at $.invoice_id. With Treat precision risks as errors, the summary becomes Precision error. Use {"invoice_id":"9007199254740993"} when exact digits matter.

FAQ:

Why does strict JSON reject a file that works in my editor?

Many editors accept JSONC or JSON5 conveniences such as comments and trailing commas. Set Parser profile to the matching format, then use Formatted JSON when the receiving system requires strict JSON.

Does valid JSON mean my API will accept it?

No. Valid JSON means the selected parser and review policies passed. An API can still reject missing fields, unsupported values, wrong root shape, or a schema rule the selected review profile does not cover.

Why is the formatted output missing?

Formatted JSON appears only after parsing succeeds. Fix the first Syntax error message from the summary or Issue Ledger, then the formatted tab can return.

Should duplicate keys ever be ignored?

Ignore them only when the receiving system's duplicate-key behavior is already known. For most handoffs, use Warn on duplicate keys or Treat duplicates as errors and fix the repeated member.

Why does a big number trigger a precision note?

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

Are selected files sent away for validation?

No upload is needed for validation. A selected file is read into JSON source in the browser, and the report outputs should be handled with the same care as the original source.

Glossary:

JSON
A text syntax for structured values such as objects, arrays, strings, numbers, booleans, and null.
JSONC
A JSON-with-comments style used for human-edited configuration, with comments removed before strict JSON output.
JSON5
A JSON extension that allows additional JavaScript-style syntax such as unquoted keys, single quotes, comments, and some number forms.
JSON Lines
A line-delimited format where each non-blank line is one complete JSON value.
Duplicate key
A repeated object member name within the same object.
Safe integer
An integer that JavaScript can represent and distinguish exactly as a number.
Primitive root
A JSON root value that is a string, number, boolean, or null rather than an object or array.

References: