JSON Formatter & Validator

How to use the JSON formatter

1. Paste your JSON into the input box.
2. Click Format / Beautify to pretty-print it (choose 2-space, 4-space or tab indent), Minify to strip whitespace, or Validate to just check it.
3. If the JSON is invalid, the message shows the exact line and column of the problem.
4. Copy or Download the result.

Format vs. validate vs. minify

Validating checks whether your text is well-formed JSON. Formatting (beautifying) re-indents valid JSON so a human can read nested structures. Minifying removes every non-essential space and newline so the payload is as small as possible — useful before sending JSON over the network or embedding it. None of these change your data: keys, values, types and key order stay exactly as written; only whitespace differs.

Common reasons JSON is invalid

• Trailing comma — {"a":1,} is invalid; JSON allows no comma after the last item.
• Single quotes — strings and keys must use "double quotes", never '.
• Unquoted keys — {name:"x"} must be {"name":"x"}.
• Comments — JSON has no // or /* */ comments.
• Wrong literals — booleans and the null value must be lowercase (true, false, null); JavaScript-only keywords are not valid JSON.
• Mismatched brackets — every { and [ needs its closing partner.

Is it private?

Yes. The tool uses your browser's native JSON.parse and JSON.stringify — nothing is sent to a server, so it is safe to paste internal API responses, tokens or config. It also works offline once the page has loaded.

What is JSON, and where did it come from?

JSON (JavaScript Object Notation) is a lightweight, text-based format for exchanging structured data. It was named and popularised by Douglas Crockford, who registered the json.org domain in 2002 and published the grammar there. JSON's syntax is borrowed from the object and array literals of the JavaScript language (specifically the ECMAScript 3 standard of 1999), but JSON itself is language-independent: parsers and serialisers exist for virtually every programming language. That is exactly why it became the default way for a browser, a mobile app and a server — often written in three different languages — to talk to one another.

JSON was first written down as an IETF specification in RFC 4627 (2006). It was later given a formal, standards-body grammar as ECMA-404 in October 2013, and the current authoritative specification is RFC 8259 (2017), which is also published as Internet Standard STD 90. RFC 8259 made one rule explicit that older documents left fuzzy: JSON text exchanged between systems must be encoded as UTF-8. The two living specifications, ECMA-404 and RFC 8259, are deliberately kept identical, and their editors have agreed to update both in lock-step if either ever changes.

The six JSON data types

Every value in a JSON document is one of just six types — there is nothing else:

• Object — an unordered set of "key": value pairs wrapped in braces. Keys must be double-quoted strings.
• Array — an ordered list of values wrapped in square brackets. Values may be of mixed types.
• String — text in double quotes, with backslash escapes such as \n, \t, \" and \uXXXX.
• Number — a decimal number such as 42, -3.14 or 6.022e23. There is no separate integer type, and NaN, Infinity and leading zeros are not allowed.
• Boolean — the lowercase literals true or false.
• Null — the lowercase literal null, meaning "no value".

A JSON document is simply one value of one of these types — most commonly an object or an array at the top level, though RFC 8259 allows any value (even a bare true or a single number) to stand alone as a complete JSON text.

Why JSON has to be so strict

JSON is intentionally a strict subset of JavaScript syntax — and even stricter than the objects you write in code. That strictness is a feature: a rigid grammar means every conforming parser reads a document the same way, with no ambiguity. The rules that trip people up most are direct consequences of this design. There are no comments — Crockford removed them deliberately so nobody could smuggle parsing directives into a data file. There are no trailing commas, because a comma is a separator and may not appear after the final element. Only double quotes are allowed for both keys and string values; the single quotes and unquoted keys you can use in JavaScript are not valid JSON. And the keywords true, false and null are case-sensitive, so True or NULL will fail.

The number-precision trap

JSON places no limit on the size or precision of a number, but most parsers — including the JSON.parse in your browser — read numbers into a 64-bit IEEE 754 floating-point value. That safely represents integers only up to 2⁵³ − 1 (9007199254740991, exposed in JavaScript as Number.MAX_SAFE_INTEGER). A 64-bit database ID or a very long numeric token larger than that will be silently rounded when parsed. The standard workaround is to transmit such values as strings and only convert them where a big-integer type is available. This is a subtle bug no formatter can warn you about, because the rounding happens inside the parser before the value ever reaches the page.

JSON vs XML vs YAML

Before JSON, XML was the dominant interchange format. XML is powerful — it supports attributes, namespaces, schemas (XSD) and validation — but it is verbose: every element needs an opening and closing tag, which inflates payload size and parsing cost. JSON expresses the same data with far less text and maps directly onto the native structures (objects, arrays, maps, lists) of most languages, which is why REST APIs overwhelmingly moved to it.

YAML is a near-superset of JSON that adds comments, anchors and a whitespace-based layout, making it popular for human-edited configuration such as CI pipelines and Kubernetes manifests. The trade-off is that YAML's indentation sensitivity makes it easy to break by hand, whereas JSON's explicit brackets are unambiguous. A useful rule of thumb: JSON for machines, YAML for humans, XML for documents with rich markup and mixed content.

Relaxed cousins: JSON5, JSONC and NDJSON

Several extensions loosen JSON's rules for specific jobs. JSONC ("JSON with Comments") simply permits // and /* */ comments and is what Visual Studio Code uses for its settings files. JSON5 goes further, allowing single quotes, unquoted keys, trailing commas and hexadecimal numbers to make hand-edited files more forgiving. NDJSON (also called JSON Lines) stores one independent JSON object per line, which is ideal for streaming logs and large datasets because a reader can process one record at a time without loading the whole file. None of these are interchangeable with strict JSON — if a server expects RFC 8259 JSON, comments and trailing commas will be rejected, which is the single most common reason a payload that "looks fine" fails to parse.

Where you will find JSON

Once you start looking, JSON is everywhere. It is the body format of the vast majority of REST and GraphQL APIs; the configuration language of countless tools (package.json, tsconfig.json, composer.json); the native document format of NoSQL databases such as MongoDB; and the payload of every JSON Web Token. Specialised dialects extend it into new domains: GeoJSON encodes maps and geographic shapes, JSON-LD powers the structured-data snippets that search engines read, and JSON Schema describes and validates the shape of other JSON documents. Knowing JSON well is one of the highest-leverage skills in modern software, because the same format reappears in so many places.

Pretty-print or minify? It depends on the reader

Beautified JSON, with indentation and line breaks, exists for one reader: a human. Minified JSON, with every optional space removed, exists for a different one: the network. For data you are about to send over the wire, minify it — but remember that HTTP responses are almost always gzip- or Brotli-compressed, and compression already collapses repeated whitespace very efficiently, so the real-world size difference after compression is usually modest. The bigger win from minifying is simply fewer bytes to parse. For anything you are reading, debugging, committing to version control or pasting into a bug report, beautify it first: a clean, indented structure makes a missing bracket or a misplaced value obvious at a glance.

A note on JSON and security

Parsing JSON is safe; evaluating it is not. In the early days some developers parsed JSON by passing it to JavaScript's eval(), which would execute any code hidden in the text — a serious vulnerability. Always use a real parser such as JSON.parse (which this tool uses) and never eval. One subtlety worth knowing: a key named __proto__ in untrusted JSON has, in some libraries, been used for "prototype-pollution" attacks. Well-maintained parsers now defend against this, but it is a good reason never to feed untrusted JSON straight into sensitive object-merging code.

JSON has no date type

A common surprise is that JSON has no native representation for dates, times or binary data — only the six types above. By overwhelming convention, dates are carried as ISO 8601 strings such as "2026-06-30T14:00:00Z", and binary blobs are carried as Base64-encoded strings. When you serialise a JavaScript Date with JSON.stringify you get an ISO 8601 string automatically, but parsing it back gives you a string, not a Date — you must convert it yourself. Treating every timestamp as UTC (the trailing Z) and converting to local time only for display is the most reliable way to avoid timezone bugs.

Duplicate keys and key order

Two further details catch people out. First, RFC 8259 says that the names within an object should be unique but does not forbid duplicates, and it leaves the behaviour of a parser that meets a repeated key undefined. In practice most parsers, including the browser's, keep the last occurrence — but you should never rely on that, and duplicate keys are a classic source of interoperability bugs. Second, although a JSON object is formally an unordered collection, every mainstream parser preserves the insertion order of keys, and this formatter keeps your keys in exactly the order you wrote them when it beautifies or minifies. If your application genuinely depends on a particular order, encode it explicitly — for example as an array of pairs — rather than trusting object key order.

Navigating JSON: JSONPath and JSON Pointer

As documents grow, you need a way to address a value deep inside them. Two small standards do exactly that. JSON Pointer (RFC 6901) uses a slash-separated path such as /users/0/email to point at one precise location — it is what JSON Patch and JSON Schema use internally to refer to a node. JSONPath is a more expressive, query-like syntax (inspired by XPath for XML) that can select many nodes at once, filter by condition and use wildcards — for example $.users[*].email to pull every user's email. Pointer answers "this one place"; JSONPath answers "everything that matches". Knowing they exist saves a lot of manual hunting through a large beautified document.

Tips for working with large JSON

Browser-based tools, including this one, comfortably handle multi-megabyte files because the work is done locally on your machine. A few habits help when documents get genuinely large. Beautify before you read so the structure is visible, but keep a minified copy for transport. For files too big to hold in memory at once, prefer NDJSON (one object per line) and process it line by line, or use a streaming parser that emits values as it reads rather than building the whole tree first. And when an API returns a large collection, look for pagination — a next cursor or page parameter — instead of requesting everything at once; well-designed APIs never expect you to download a million records in a single response.

Frequently asked questions

Is my JSON uploaded to a server?

No. Formatting, validating and minifying all run in your browser with JavaScript. Your data never leaves your device, which makes the tool fast and safe for sensitive payloads.

Why is my JSON invalid?

The most common causes are a trailing comma after the last item, single quotes instead of double quotes, unquoted object keys, comments (JSON has none), or a missing bracket/brace. This tool points you to the exact line and column where parsing failed.

What is the difference between formatting, validating and minifying?

Validating checks whether the text is well-formed JSON. Formatting (beautifying) re-indents valid JSON so it is readable. Minifying strips all whitespace to make it as small as possible for transport. This tool does all three from one box.

Does formatting change my data?

No. Beautifying and minifying only change whitespace — the keys, values, types and structure are identical. Object key order is preserved as written.

How large a file can it handle?

Because it runs in your browser, it comfortably handles typical API responses and config files (multiple MB). Extremely large files are limited only by your device memory, not an upload limit.

Related developer tools

• JSON to CSV
• JSON to XML
• JSON to HTML table
• CSV to JSON
• Base64 Encoder / Decoder

See all developer & data conversions →