The simplest JSON formatter can be built in a few lines: parse the input, then serialize it with indentation.
That approach works until the document contains a 20-digit identifier, a high-precision decimal, an extreme exponent, a truncated response, an escaped JSON string, or a structure large enough to require real editing and search.
JSONDock is built for that less ideal—and more realistic—version of the task.
Formatting is the entry point, not the product
People rarely open a JSON tool because the document is already perfect.
They may be debugging an API response, inspecting exported data, recovering a log entry, comparing a nested payload, preparing data for another system, or trying to understand why a parser rejected a document.
Those workflows need more than a “Format” button. JSONDock brings several related operations into one browser workspace:
- Format and validate JSON.
- Repair malformed or truncated documents.
- Decode escaped JSON.
- Minify output.
- Search inside the editor.
- Explore values as a tree or table.
- Convert JSON to XML.
Keeping these actions together reduces the need to paste the same document through a chain of unrelated websites.
Why ordinary JavaScript parsing can be dangerous
JSON supports numbers without defining the precision limits imposed by a specific programming language. JavaScript’s standard Number type uses IEEE 754 double-precision floating point.
That means an integer larger than Number.MAX_SAFE_INTEGER, a high-precision decimal, or an extreme exponent may not survive a normal parse-and-stringify cycle exactly.
For an obvious calculation this may be acceptable. For identifiers, financial values, scientific data, or database exports, silent rounding is a serious problem.
Many lightweight JSON formatters use the standard JSON.parse and JSON.stringify path because it is convenient. The result can look beautifully formatted while no longer being byte-for-byte faithful to the original number tokens.
JSONDock uses lossless-json to preserve large integers, precise decimals, and extreme exponents in their original textual form. Formatting should change whitespace and structure visibility—not quietly rewrite the data.
This is one of the product’s most important technical advantages, even though the best outcome is that users never have to think about it.
Repair should be deterministic and reviewable
Malformed JSON is common. A response may be cut off halfway through transmission. A comma may be missing. Keys may be unquoted. A log line may contain a JSON-like fragment rather than a valid document.
JSONDock uses jsonrepair for deterministic repair. The same input produces the same proposed output, and the result is presented as something the user should review.
That wording matters.
Repair is not the same as knowing the author’s intent. A tool can close brackets, quote keys, or complete common structural mistakes, but it should not pretend that every repaired document is semantically correct.
Compared with opaque “AI repair” flows, deterministic repair has useful properties:
- It works locally.
- It does not send potentially sensitive payloads to a model or API.
- It is repeatable.
- It is easier to test.
- The scope of the transformation is easier to understand.
This does not make deterministic repair infallible. It makes the behavior more predictable and the privacy model clearer.
A real editor changes the workflow
A plain <textarea> is enough for a tiny formatter demo. It becomes frustrating as soon as a document grows.
JSONDock uses CodeMirror 6 to provide:
- Line numbers.
- Undo history.
- Bracket matching.
- Code folding.
- Indentation behavior.
- Cursor-aware editing.
- Editor search.
These are not decorative developer features. They reduce the distance between finding a problem and fixing it.
The document remains the center of the interface. Tree and table views help with exploration, but they do not replace the editable source or force the user into a separate application state.
Conversion without handing data to another service
JSON-to-XML conversion also happens locally.
Arrays become repeated <item> elements. Original number tokens remain lossless. JSON keys that cannot be used as valid XML element names are represented as <property name="…"> rather than producing broken markup or silently discarding the key.
That behavior reflects a broader principle: conversion needs explicit rules for awkward cases. A successful output string is not enough if the transformation loses information.
English and Chinese as first-class entry points
JSONDock is available in English at json.iwebtools.net and in Chinese at json.iwebtools.net/zh/.
The Chinese version is not a browser-translation layer. It has a localized interface and localized search metadata, while both versions declare reciprocal language links.
For a developer utility, localization can be underestimated because the data format itself is universal. The error message, action label, explanation, and search query are not. A first-class localized interface reduces friction without changing the underlying transformation logic.
How JSONDock differs from common alternatives
JSON tools generally fall into a few groups:
- Minimal formatters that parse and indent a document.
- Large utility portals that place JSON among dozens or hundreds of unrelated tools.
- Desktop editors or IDE features that are powerful but require installation and setup.
- Hosted workspaces that add accounts, storage, collaboration, or server-side processing.
JSONDock deliberately sits between the first and third groups.
It offers more safety and editing depth than a minimal formatter, but opens immediately like a web tool. It avoids turning a focused JSON task into a general-purpose portal or account-based workspace.
Its current advantages are concrete:
- Lossless number handling.
- Deterministic local repair.
- A full CodeMirror editing experience.
- Tree and table exploration.
- Local XML conversion with explicit edge-case rules.
- English and Chinese interfaces.
- No backend, accounts, analytics, or document storage.
The tradeoff is equally clear: JSONDock does not currently provide cloud synchronization, team collaboration, remote schemas, or persistent workspaces. Those features may be valuable products, but they would change the architecture and privacy model. They should not be added casually.
What comes next
The near-term work is to deepen the document workflow without weakening its foundations.
Potential improvements include stronger navigation for large documents, more useful diagnostics around repair, additional local export options, and continued accessibility and mobile refinement.
Any remote lookup, persistence, account system, analytics, or hosted collaboration feature would require an explicit product decision and privacy review. “Input stays in the browser” is only meaningful if the architecture continues to make it true.
JSONDock is not trying to become an online IDE. It is trying to be the JSON workspace that is ready at the moment a document becomes messy—and careful enough not to make the data worse.