Free JSON Formatter & Validator

Validate JSON before debugging your Android model

This formatter uses the browser's JSON.parse and JSON.stringify to check syntax and rewrite a document with consistent indentation. It is useful for isolating a malformed API response before investigating Retrofit adapters or Kotlin models. Formatting does not validate your API contract, prove that a response is trustworthy, or run an Android parser. Work with a redacted copy: account tokens, device identifiers, and private messages do not belong in shared debugging examples.

JSON syntax and RFC 8259 interoperability

A JSON value can be an object, array, string, number, boolean, or null, including at the document root. Object names and strings require double quotes. Separate members and array elements with commas, without a trailing comma. Comments, single-quoted strings, undefined, NaN, and Infinity are not JSON syntax. Escape quotation marks, backslashes, and control characters inside strings. A literal line break inside a string must be represented by an escape such as \n.

RFC 8259 requires UTF-8 for interchange outside closed ecosystems. Object names should be unique: duplicate names can parse successfully but produce inconsistent results across implementations. This tool keeps the last duplicate property when it rewrites the object; it is not a duplicate-key detector. JSON numbers also have no universal implementation precision. JavaScript cannot represent every integer beyond 2^53 - 1 exactly, so preserve large identifiers as strings in your API and keep the original response before formatting.

Choose a Kotlin parser by behavior

kotlinx.serialization fits projects sharing annotated models across Kotlin platforms. Moshi supports Kotlin through code generation or its Kotlin reflection adapter; plain Java reflection is insufficient for Kotlin classes. Gson remains relevant to existing Java codebases, but its maintainers highlight limitations around Kotlin language features and Android shrinking. Switching libraries requires compatibility tests for missing fields and nulls, not just changing a dependency declaration.

Parsing benchmarks: measure your workload

No timing results are claimed here: this browser utility cannot benchmark Kotlin libraries on your phone. A useful comparison uses AndroidX Microbenchmark on a physical device and records device model, Android version, library versions, compiler configuration, and build variant. Use identical models and payload bytes with each library. Include a small object, a nested response, and a large list drawn from a sanitized real API fixture. Verify decoded values before comparing performance.

Create parsers and adapters outside the measured block when measuring steady-state decoding. Measure cold setup separately if startup matters. Let the benchmark framework handle warmup and repeated measurements; avoid mixing HTTP calls, disk reads, logging, or UI rendering into parsing time. Record latency and allocation metrics, and repeat the comparison under the same thermal conditions. Generated Moshi adapters and reflection adapters should appear as separate configurations.

Throughput in MiB/s = payload bytes × operations / elapsed seconds / 1,048,576. An illustrative 10,240-byte fixture decoded 1,000 times in two seconds yields 4.88 MiB/s; this is arithmetic, not a measured result. Report the fixture and methodology alongside results so another developer can reproduce them. A faster parser that silently changes missing-field behavior is not a successful migration.

Troubleshoot common failures

An unexpected less-than sign near the start often means the server returned HTML, such as a login page or proxy error. Check the HTTP status and Content-Type before changing the model. Unexpected end of input suggests truncation or an unfinished array or string; compare the received byte count with the captured response. A property-name error often comes from single quotes or a trailing comma. Fix the earliest reported location before chasing later errors.

When JSON syntax is valid but Android decoding fails, inspect the reported field path. A string containing digits is still a string, an object is not a list, and null differs from a missing property. Decide unknown-key handling explicitly to support API evolution without concealing required-field errors. A byte-order mark, double-encoded JSON string, or accidental escape layer can also explain why a response looks correct in a log but fails in production.

Technical references

Consult RFC 8259, Kotlin serialization, Moshi, Gson, and AndroidX Microbenchmark for implementation details.

Frequently asked questions

Published by AndroidRich. Technical content updated 4 October 2026. Report a correction.