JSON Validator & Formatter
Validate, format, minify, and visualize JSON in an interactive tree view.
What Is JSON?
JSON (JavaScript Object Notation) is a lightweight, text-based data interchange format defined in RFC 8259 (and ECMA-404). Despite its name, JSON is language-independent: it is parsed natively by Python, Java, Go, Ruby, Rust, Swift, and every other major language without external dependencies. JSON originated as a subset of JavaScript object literal syntax — Douglas Crockford formalized it in the early 2000s — but it has long since outgrown that origin. Today it is the universal lingua franca for REST APIs, GraphQL responses, configuration files (package.json, tsconfig.json, .eslintrc), NoSQL document stores (MongoDB, Firestore, DynamoDB), and inter-service communication in microservice architectures.
JSON's data model is deliberately minimal: exactly six value types are defined. Primitive types: string (Unicode, double-quoted), number (IEEE 754 double-precision float, no integer/float distinction in the spec), boolean (true or false), and null. Structural types: object (an unordered set of zero or more key-value pairs where keys must be strings) and array (an ordered sequence of values). Values can be nested to arbitrary depth. This simplicity is both a strength (any system can parse JSON without ambiguity) and a limitation: JSON natively has no date type, no binary type, no integer vs. float distinction, no undefined value, no comments, and no circular references — all common sources of surprise for developers coming from more expressive formats.
Despite JSON's conceptual simplicity, invalid JSON is one of the most frequent causes of silent failures and cryptic error messages in real development. The five most common JSON syntax errors are: (1) trailing commas after the last element in an object or array ({"a": 1,} — trailing comma is forbidden by RFC 8259 but permitted in JSONC/JSON5); (2) single-quoted strings instead of double-quoted ('value' instead of "value"); (3) unquoted keys ({key: value} instead of {"key": value}); (4) missing commas between elements; and (5) comments (// or /* */, which are not part of standard JSON). A JSON formatter and validator catches these instantly — before they manifest as a 500 error in production or a SyntaxError in your CI pipeline.
How to Use This JSON Formatter
Our JSON Formatter provides three output modes: an interactive tree view for exploring structure, formatted (pretty-printed) output for readability, and minified output for production use.
- Paste or Upload — Paste your JSON string into the input area, or upload a .json file from your device. The tool accepts any valid JSON value — not just objects; a top-level array, string, or number is also valid JSON per RFC 8259.
- Validate & Format — Click the button or press Ctrl+Enter. If the JSON is valid, a green confirmation appears and the tree view, formatted output, and minified output are all generated simultaneously. If the JSON contains a syntax error, the error message includes the position (line and character offset) where parsing failed.
- Switch Views — Use the Tree / Formatted / Minified tabs to toggle between an interactive collapsible tree (ideal for exploring unknown API response structures), pretty-printed JSON with 2-space indentation (ideal for documentation and code reviews), and a compact single-line minified version (ideal for production API bodies and size measurement).
- Copy Output — Click "Copy" to copy the current view's output to your clipboard. The copy confirms success immediately, so you can paste into your editor, API client (Postman, Insomnia), or documentation without additional steps.
Everything runs client-side in your browser using JavaScript's native JSON.parse() and JSON.stringify() APIs. Your JSON data is never uploaded to any server, never stored, and never transmitted — fully GDPR-compliant for processing sensitive API responses, database exports, and configuration files containing credentials or PII. Free users can process up to 100 KB; Pro users have no limit.
How It Works
When you click "Validate & Format", the browser passes your JSON string to JSON.parse() — the native JavaScript JSON parser built into the V8, SpiderMonkey, or JavaScriptCore engine. This parser validates syntax strictly according to RFC 8259 and, if successful, converts the JSON text into a live JavaScript object graph. Any syntax error causes JSON.parse() to throw a SyntaxError with a message describing the problem, which our tool extracts and displays with the error position.
For the interactive tree view, our React-based renderer recursively traverses the parsed JavaScript object. Each key-value pair is rendered as a collapsible component with type-specific color coding: strings appear in green (the most common type in API responses), numbers in blue (easy to distinguish from string-encoded numbers), booleans in amber (true/false at a glance), and null values in rose/pink (immediately visible as absent values). Object and array nodes show their child count in a badge when collapsed.
Formatted output is produced by JSON.stringify(data, null, 2), which serializes the parsed JavaScript object back to JSON text with 2-space indentation at each nesting level. Minified output uses JSON.stringify(data) without the indentation argument — this removes all whitespace between tokens and typically reduces file size by 20–40% compared to formatted output, depending on the amount of whitespace in the original. Both outputs preserve the exact data values, key order (as parsed), and Unicode content of the original JSON.
Use Cases
REST API Response Debugging
Copy a raw JSON response from browser DevTools (Network tab → Response), Postman, Insomnia, or curl --silent output and paste it into our formatter. The tree view lets you navigate deeply nested structures — useful for exploring paginated API responses with embedded metadata, error objects with nested validation details, or large GraphQL query results. Collapse top-level arrays to count elements, then expand individual items to inspect their schema.
Configuration File Validation
package.json (Node.js project manifest), tsconfig.json (TypeScript compiler options), .eslintrc.json (ESLint rules), .prettierrc (Prettier configuration), launch.json (VS Code debugger), and devcontainer.json are all JSON files where a single misplaced comma or missing bracket causes cryptic tool failures. Our validator catches syntax errors immediately, reports the exact position, and formats the file for readability — all before you commit the change.
Production API Payload Minification
When building REST or GraphQL APIs that serve mobile clients, every byte of response size matters for latency and data plan costs. The minified tab shows the single-line version of your JSON with all non-semantic whitespace removed. Measure the formatted vs. minified size to understand the savings — for deeply nested API responses with many string keys, minification typically saves 20–40%. The minified output can be pasted directly into API response fixture files or network mocking libraries.
NoSQL Document and Schema Exploration
MongoDB documents, DynamoDB items, Firestore documents, and Elasticsearch _source objects are all JSON. When exported via mongoexport, the AWS CLI, or a database admin tool, they often arrive as minified single-line JSON. Our tree view transforms any single-line JSON into a fully navigable hierarchy — ideal for understanding the structure of an unfamiliar collection, exploring nested subdocuments, or verifying that a document migration script produced the expected output.
Example: JSON Validation and Formatting
Here is a typical JSON response representing an API validation error — the kind you might receive from an XRechnung processing endpoint or any REST API with server-side validation. Paste it and click Validate to see all three views:
{
"status": "error",
"code": 422,
"message": "Validation failed",
"errors": [
{
"field": "invoice_date",
"rule": "required",
"message": "Invoice date is required"
},
{
"field": "seller_vat_id",
"rule": "format",
"message": "VAT ID must start with DE followed by 9 digits"
}
],
"timestamp": 1700000000,
"request_id": "f47ac10b-58cc-4372-a567-0e02b2c3d479"
}This example shows a JSON object containing a nested array of error objects, a Unix timestamp integer, and a UUID string. Notice that timestamp (an integer) and request_id (a string) are different types — the tree view color-codes these immediately.
Tips & Limitations
Tips
- Use Ctrl+Enter for quick validation without reaching for the mouse — especially useful when iterating on a JSON payload in a tight edit-validate loop.
- The tree view color-codes all six JSON data types: strings (green), numbers (blue), booleans (amber), null (rose/pink), objects (labeled with key count), and arrays (labeled with element count). This makes type mismatches immediately visible — for example, a date stored as a number instead of a string.
- Minified JSON can be pasted directly into API request bodies in Postman, Insomnia, or curl -d '...' commands. It can also be stored as a one-liner in database TEXT columns or used as a compact fixture in unit tests.
- The tree view expands to depth 2 by default, showing top-level keys and their immediate children. Click any object or array node to collapse it — useful when a response has many top-level keys and you want to focus on a single section.
Limitations
- Standard JSON (RFC 8259) does not support comments (// or /* */), trailing commas, or unquoted keys. If your input contains these, it is JSONC (JSON with Comments, used by VS Code) or JSON5 — both require dedicated parsers. Remove comments and trailing commas before using our validator.
- Free users can process a maximum of 100 KB. A Pro account is required for larger files. A 100 KB JSON file is roughly 1,000–3,000 typical API response objects — sufficient for nearly all debugging use cases.
- Very deeply nested JSON (>50 levels) may slow tree rendering since each level is a React component subtree. In practice, real-world API responses rarely exceed 10–15 levels of nesting.
- JSON numbers are limited to IEEE 754 double-precision float range. Integers larger than 2^53 - 1 (9,007,199,254,740,991) or smaller than -(2^53 - 1) cannot be represented exactly in JSON and may be silently rounded. For large integers (database IDs, financial amounts in minor units), use JSON strings instead of numbers.
Frequently Asked Questions
Can I validate JSON with comments (JSONC)?
Standard JSON (RFC 8259) does not support comments. If your JSON contains // single-line or /* */ multi-line comments, it is not valid JSON — it is JSONC (JSON with Comments) or JSON5. VS Code configuration files (settings.json, launch.json, tsconfig.json) use JSONC. Before validating, you must strip comments manually or use a JSONC-aware parser. Our tool reports the exact position of the comment character as a syntax error, making it easy to find and remove comments.
What is the difference between formatted and minified JSON?
Formatted (pretty-printed) JSON uses 2-space indentation and newlines after each key-value pair and array element, making the structure immediately human-readable. Minified JSON removes all whitespace between tokens — no spaces, no newlines — producing the most compact possible representation. The data content and value types are identical in both versions; only the whitespace differs. Minification typically reduces JSON size by 20–40%, depending on how much whitespace was present. Use formatted JSON for code reviews, documentation, and debugging; use minified JSON for production API responses, network transfers, and any context where file size matters.
Is my JSON data sent to a server for processing?
No. All JSON parsing, formatting, tree rendering, and minification run entirely in your browser using the JavaScript engine's native JSON.parse() and JSON.stringify() methods. Your JSON data never leaves your device, is never stored on any server, and is never used for analytics or training. This makes docutools.pro safe for formatting JSON that contains API credentials, authentication tokens, personal data, medical records, or any other sensitive content.
What causes 'Unexpected token' and 'Unexpected end of JSON input' errors?
The five most common JSON syntax errors: (1) Trailing comma — a comma after the last element in an object or array: {"a": 1,} or [1, 2,]. Allowed in JavaScript and JSONC but forbidden in RFC 8259 JSON. (2) Single-quoted strings — JSON requires double quotes: 'value' must be "value". (3) Unquoted property names — JavaScript allows {key: value} but JSON requires {"key": value}. (4) Missing comma between elements — {"a": 1 "b": 2} is missing a comma. (5) Comments — // or /* */ in JSON source. Our formatter reports the exact character offset where parsing failed, making it easy to locate the problem.
What is the maximum JSON file size this tool supports?
Free users can process JSON files up to 100 KB — sufficient for the vast majority of debugging tasks. A typical REST API response is 1–10 KB; a large paginated response with 100 items might be 50–80 KB. Pro subscribers can process files of any size, including large database exports (mongoexport, pg_dump JSON format), full GraphQL schema introspection JSON (often 500 KB–2 MB), and multi-megabyte event logs or analytics dumps.
Can JSON represent all data types I work with in my language?
JSON's type system is intentionally minimal: string, number (IEEE 754 float), boolean, null, object, array. Types commonly needed but not natively representable: Dates (represent as ISO 8601 strings: "2025-04-15T14:30:00Z"), binary data (represent as Base64 strings), integers vs. floats (JSON has a single number type — use a JSON Schema discriminator or naming convention if your application needs the distinction), undefined (not representable — omit the key entirely), and infinity/NaN (not valid JSON numbers — use null or a special string sentinel). These limitations are by design, keeping JSON universally parseable without language-specific type knowledge.
What is JSON Schema and how is it different from JSON validation?
JSON syntax validation (what our tool does) checks that a string is parseable as JSON per RFC 8259 — correct brackets, quoted keys, valid value types, no trailing commas. JSON Schema (jsonschema.org, used in OpenAPI, AsyncAPI) is a separate vocabulary for describing the expected structure, required properties, value constraints (minimum, maximum, pattern, enum), and nested object shapes of a JSON document. A JSON document can be syntactically valid but structurally invalid (missing required fields, wrong types) according to a Schema. Client-side Schema validation typically uses Ajv (for JavaScript/Node.js) or jsonschema (for Python). OpenAPI Generator and similar tools use JSON Schema to generate type-safe API client code.
Is JSON better than XML for API data exchange?
For most REST APIs and web browser applications, JSON is the pragmatic choice: it is more compact, directly maps to JavaScript objects, and is universally parseable without namespace or schema knowledge. However, XML has technical advantages that make it preferred in specific contexts: namespaces (crucial for document standards like XRechnung that combine multiple vocabularies), mixed content (text interleaved with markup, as in word processors), formal schema validation (XSD is more expressive than JSON Schema in some areas), and transformation (XSLT). German e-invoicing (XRechnung, ZUGFeRD) uses XML precisely because of these features — a valid XRechnung invoice must satisfy multiple overlapping schemas and Schematron rules that would be difficult to express in JSON Schema.
How do I handle special characters and Unicode in JSON strings?
JSON strings must use double quotes and escape six characters with backslash sequences: \" (double quote), \\ (backslash), \/ (forward slash — optional but allowed), \b (backspace), \f (form feed), \n (newline), \r (carriage return), \t (tab). Unicode characters outside ASCII can be included directly in UTF-8 encoded JSON (the recommended approach — e.g., German ä directly as ä) or escaped as \uXXXX four-hex-digit sequences (e.g., \u00e4 for ä). Our formatter preserves direct Unicode characters as-is; if your target system requires ASCII-only JSON (some older parsers), use a library's ASCII-escape option when serializing.
What is the difference between JSON and JSONP?
JSON is a data format. JSONP (JSON with Padding) is a historical web technique for making cross-origin data requests before CORS (Cross-Origin Resource Sharing) was standardized. In JSONP, a server wraps a JSON payload in a function call: callback({"data": ...}). The browser loads it as a <script> tag, which calls the named function with the JSON data. JSONP is not valid JSON (it is a JavaScript expression), has significant security risks (it executes arbitrary JavaScript), and is obsolete — modern applications use CORS-enabled APIs or CORS proxies. Our JSON validator will reject JSONP because the wrapper function call is not valid JSON syntax.