jsoning.com

What is JSONing?

JSONing is a browser-based collection of utilities for working with JSON and related data formats. Rather than a single-purpose tool, it bundles many small converters, validators and generators in one place, so you can move between tasks like formatting, comparing or converting data without switching sites. It is aimed at developers and IT professionals who handle JSON in APIs, configuration files or data pipelines.

The toolset covers several practical areas:

• Formatting and validation: JSON Formatter, JSON Validator, JSON Linter and a JSON Fixer that uses AI to repair malformed input.
• Transformation and conversion: JSON to JSON Schema, JSON to Protobuf, JSON to JSONL, CBOR to JSON, CSV to JSONL and JSON to Toon.
• Inspection and comparison: JSON Compare, JSONPath Tester, JSON Patch Generator and JSON Merger.
• Generation and testing: JSON Generator, Mock API and JSON samples.
• JSONL support: A dedicated JSONL validator alongside the JSONL conversion tools.

A useful way to think about it is as a toolbox rather than a platform. If you need one quick conversion — say, turning a CSV export into JSONL for a streaming pipeline — you can do that directly. If you need to debug a malformed API response, the validator and fixer are right there. The trade-off is that a broad toolbox may not go as deep as a specialised editor for large or complex projects, and the AI-assisted fixer is best treated as a convenience rather than a guarantee of correctness. Always verify repaired output against your schema or tests.

As a next step, pick the task you actually have in front of you and start with the matching tool: validate first if the data is suspect, convert only after it parses cleanly. For a concrete scenario, a backend developer receiving a broken JSON payload from a third-party API could paste it into the validator, use the fixer to get a starting point, then confirm the corrected structure with the JSONPath Tester before writing it into a test fixture.

How do I validate or fix a JSON file with JSONing?

JSONing offers two separate routes for this: a JSON Validator for checking whether a file is well-formed, and a JSON Fixer for repairing one that fails. They are different tools, so pick based on whether you already know the file is broken.

Validate first if you are unsure. Paste or load your JSON into the validator. It tells you whether the document parses and, if not, where the problem is — typically the line and character position of the offending token. That is usually enough to fix a stray trailing comma, a missing brace or an unquoted key yourself.

Use the fixer when the error is not obvious. The JSON Fixer is aimed at malformed input where the fault is structural or hard to spot by eye — mismatched brackets, single quotes instead of double quotes, comments left in the file, or values pasted from a log. It attempts to produce valid JSON from that input. Treat the output as a draft: check that no fields were dropped, that numbers were not silently reinterpreted as strings, and that nested arrays still hold the same number of items.

A concrete workflow. Suppose you exported API responses and one record fails to load. Run the file through the JSON Validator, jump to the reported offset, and if the surrounding text looks fine but the parser still complains, run the same content through the JSON Fixer. Then compare the two versions field by field — a diff tool or a quick JSON Compare pass inside JSONing will show what changed. If your data is one object per line rather than a single document, use the JSONL validator instead; a standard validator will reject the whole file on the first bad line, while the JSONL tool isolates it.

One decision rule: if the fixer changes more than the specific error you identified, don't trust the result for anything that matters — regenerate the data at the source instead. For related formats, JSON.org documents the grammar itself, which is useful when you want to understand why a construct is invalid rather than just have it repaired.

Which JSONing tool should I use to compare two JSON documents?

Use JSON Compare on JSONing. It is the tool listed for putting two JSON documents side by side and spotting structural or value differences, rather than formatting or validating a single document.

JSONing

How can I query specific values in a JSON document using JSONPath on JSONing?

Use JSONing's JSONPath Tester to point at a JSON document, enter a JSONPath expression, and read the matching values from the result. It is a browser-based way to try a path before you commit it to application code.

Typical workflow:

1. Paste or load your JSON into the tester.
2. Enter an expression, for example $.store.book[*].title to list every book title, or $..price to collect all prices at any depth.
3. Inspect the returned matches. If the result is empty, the path is wrong for that document shape, not necessarily an error in the tool.
4. Copy the working expression into your code, API test or data pipeline.

JSONPath suits documents where you know roughly where a value lives but not its exact position. Common practical cases:

• Pulling one field out of a large API response, such as an ID or status.
• Extracting a list of values across nested objects, like all prices or all user emails.
• Checking a filter condition, such as items above a threshold, before writing a validation rule.
• Prototyping a query that will later run in a language library or monitoring tool.

Two cautions. JSONPath implementations differ: a path that works in one library may behave differently in another, especially around filters, recursive descent and missing keys. And JSONPath is for reading, not editing; to change a document you need a transformation step, such as JSON Patch, which JSONing also lists.

If you are deciding between tools, the practical trade-off is convenience versus integration. A browser tester is fastest for learning and debugging a path; a library inside your own code is what you ship. For related formats, JSONL tools on the same site help when each line is a separate JSON object, and a JSON formatter makes the structure easier to read before you write a path. For the JSONPath specification and behaviour details, see JSONPath.

Can JSONing convert between JSON and other formats like CSV, Protobuf, or CBOR?

Yes. JSONing includes converters in both directions for several adjacent formats, and its tool list covers exactly the cases you named.

What the site lists

• CSV to JSONL — turn tabular rows into line-delimited JSON objects, one per row.
• JSON to Protobuf — generate a Protobuf definition from a JSON sample.
• CBOR to JSON — decode CBOR (binary JSON) into readable JSON.
• JSON to JSONL — flatten a JSON array or document into JSON Lines.
• JSON to Toon — convert to a compact, LLM-oriented representation.
• JSON to JSON Schema — derive a schema rather than another data format.

So CSV and CBOR are covered as inbound conversions, Protobuf as outbound. If you need the reverse of any of those (Protobuf to JSON, JSON to CBOR, JSONL to CSV), that direction isn't listed, so plan around it.

How to pick the right one

A concrete scenario

You've exported a CSV of support tickets and want to load them into a log pipeline that ingests JSONL. Run it through CSV to JSONL, then check the result with the JSONL validator rather than assuming the header row mapped cleanly — type inference on columns like ticket IDs or timestamps is where conversions usually go wrong.

Next step

Start with a small slice of your data, convert it, and validate the output before running the full file. The JSONing toolbox groups these converters alongside validators, so you can convert and verify in the same place.

How do I generate a mock API or JSON Schema with JSONing?

For generating either a Mock API or a JSON Schema, JSONing treats them as two separate tools rather than one combined workflow. You provide a JSON sample that represents the shape of your data, and each tool derives something different from it.

• JSON to JSON Schema produces a schema describing the structure of your JSON — the fields, their types and nesting — which you can then use for validation or documentation.
• Mock API turns a JSON sample into an endpoint that returns that kind of data, so front-end code or tests can call a URL instead of a real backend.

A practical way to decide: if you need to check incoming data against a contract, start with the schema; if you need something to call while the real service is still being built, start with the mock endpoint. The two often pair well — define the schema first, then stand up a mock that returns data matching it.

A concrete scenario. Suppose you are building a checkout screen and the orders API is not ready. Paste a representative order object into the Mock API tool and point your front-end at the generated endpoint. Later, when the real API appears, generate a JSON Schema from the same sample so responses can be validated against the agreed shape. Keeping one sample as the single source for both reduces drift between the mock and the contract.

What to watch for. A generated schema reflects only the sample you supply, so optional fields, nulls and arrays with mixed types may be described too narrowly or too loosely — review and adjust before relying on it. Mock data is likewise synthetic; it is fine for layout and wiring, but not a substitute for testing real edge cases and error responses. Related tools on the same site, such as the JSON Validator, JSON Compare and JSONPath Tester, are useful for checking the samples you feed in.

Next step: open JSONing, pick the tool that matches whether you need to call an endpoint or validate a payload, and start from the smallest JSON sample that still shows every field you care about.