What Is JSON?
JSON is a way of writing structured data as plain text. It has six kinds of value, a grammar short enough to print on a postcard, and no opinion whatsoever about what your data means — which is most of the reason it took over.
This guide covers what the format actually is, where it came from and why it won, the parts of the specification that surprise people who have used it for years, and where it genuinely falls short. If you are here because a parser has rejected something, the [error-by-error breakdown](/articles/why-your-json-is-invalid) is the faster route.
The whole format, in one example
Most formats need a tutorial. JSON needs an example:
{
"name": "Ada Lovelace",
"born": 1815,
"active": false,
"languages": ["English", "French"],
"address": { "city": "London", "postcode": null }
}
That is essentially all of it. An object is a comma-separated list of "name": value pairs inside braces. An array is a comma-separated list of values inside brackets. Values are objects, arrays, strings in double quotes, numbers, the literals true and false, or null. Both containers nest inside each other to any depth.
The economy is the point. There are no dates, no binary type, no comments, no attributes, no namespaces, no schema declaration, no processing instructions. A parser for it is a weekend project rather than a library you adopt, which is why every language has three of them.
What the format leaves out is as important as what it includes, and it is worth being precise about who decided that. ECMA-404 states its goal plainly: "The goal of this specification is only to define the syntax of valid JSON texts. Its intent is not to provide any semantics or interpretation of text conforming to that syntax." JSON tells you that 1815 is a number. Whether it is a year, a quantity or a customer ID is between you and whoever sent it.
Where it came from, and why it won
JSON was specified in the early 2000s, taking its syntax from JavaScript object literals — hence the name — at a point when the alternative for moving structured data between a browser and a server was XML.
It won for reasons that had little to do with elegance. In a browser, a JSON response was already the shape you wanted: parse it and you have an object, with no traversal API, no node types and no document model in between. XML needed a DOM and a mental model; JSON needed one function call. As browser applications became the dominant way software was delivered, the format that cost nothing on the client side became the format APIs spoke.
Standardisation came later and, unusually, twice over. RFC 8259 was published in December 2017 as STD 90, superseding two earlier RFCs; ECMA-404's second edition landed the same month. The two describe the same grammar deliberately, so "valid JSON" means one thing rather than two.
One consequence of that history is worth knowing, because it changes what you can send. The original 2006 specification required the top level of a JSON document to be an object or an array. RFC 8259 removed that restriction: "A JSON text is a serialized value", which means a bare string, number or true is now a complete, valid JSON document. Old parsers may disagree, and some APIs still reject it, but the specification does not.
The parts that surprise people
Nobody reads a format specification for something they already use daily. These are the clauses that catch experienced developers out, and all four come straight from RFC 8259.
Duplicate keys are not forbidden. The specification says names within an object "SHOULD be unique" — a recommendation, not a requirement — and warns that when they are not, "the behavior of software that receives such an object is unpredictable". In practice most parsers keep the last occurrence and discard the rest silently, which is a quiet way to lose data. Nothing in the format stops a producer from emitting the same key twice.
Key order is not yours to rely on. RFC 8259 observes that parsing libraries "have been observed to differ as to whether or not they make the ordering of object members visible to calling software". An object is an unordered bag of named values. If order carries meaning, that is what arrays are for.
Numbers are where interoperability actually breaks. JSON's grammar allows a number of any length, but the specification is candid that implementations generally use IEEE 754 double precision, and that integers are interoperable only in the range −(2^53)+1 to (2^53)−1. Send a 19-digit database ID or a Twitter snowflake as a JSON number and a JavaScript consumer will round it. The universal workaround is to send large identifiers as strings, and it is a workaround rather than a fix.
There are no comments. Not omitted by accident, and not something a parser may be lenient about: the grammar has no production for them, so a conforming parser must reject a file containing one. Formats that add them — JSON5, JSONC, the config dialect your editor accepts — are different formats that happen to resemble this one.
And no date type
The omission people trip over most often is dates. JSON has no date type, so every date in every JSON payload is a string or a number by convention.
The convention that has effectively won is ISO 8601 in UTC — "2026-09-07T14:30:00Z" — because it sorts correctly as text, carries its own timezone, and every language can parse it. Unix timestamps as numbers are the other common choice, and they run straight into the precision issue above once anyone uses milliseconds.
What matters is that this is a convention between you and the other end, not a rule the format enforces. Nothing will tell you that the sender meant seconds when you assumed milliseconds; the data will simply be wrong by a factor of a thousand.
What you use it for
Four jobs account for most JSON in the world.
API payloads. The dominant use, and the reason the format is ubiquitous. A REST or GraphQL endpoint returns JSON; your code turns it into objects; nobody thinks about the format at all until something malformed arrives.
Configuration. package.json, tsconfig.json, composer.json, and a thousand tool configs. This is JSON used slightly against its grain — configuration files want comments, and JSON has none, which is why the ecosystem quietly invented JSONC and why so much configuration has migrated to YAML and TOML.
Storage and logging. Document databases store JSON or something very like it, and structured logging usually means one JSON object per line, which makes a log file greppable and machine-readable at once.
Data interchange between anything and anything. Every language reads it, which makes it the default answer when two systems need to agree on a format and have nothing else in common.
Where JSON is the wrong choice
A pillar that only lists strengths is advertising. Four cases where reaching for JSON is a mistake:
Binary data. JSON is text, so an image or a PDF has to be Base64-encoded first, which inflates it by about a third and buys you nothing. Send binary as binary.
Very large datasets. JSON is not streamable in any natural way — an array of a million records is one syntactic unit, so a naive parser wants the whole thing in memory before yielding anything. Newline-delimited JSON (one object per line) is the usual escape hatch, and formats like Parquet or Avro exist because at real scale JSON's verbosity and parse cost stop being free.
Documents with mixed content. Marked-up prose — text with emphasis and links inline — is what XML was designed for, and JSON models it awkwardly at best. If your data is a document rather than a record, the comparison with XML is worth reading before you commit.
Anything needing comments or human editing at scale. See configuration above. A file humans maintain benefits from being able to explain itself.
Numbers deserve one more mention because the failure is so quiet. If your data contains identifiers longer than about 15 digits, high-precision decimals, or money, decide deliberately how they cross the wire. Strings for IDs, minor units as integers for currency. The alternative is discovering the rounding in production.
The things built on top of it
Because the format itself is deliberately minimal, most of what people need from JSON in practice lives in separate standards layered over it. Knowing the names saves reinventing them.
JSON Schema describes the permitted shape of a document — required fields, types, ranges, patterns — and is what you reach for when "is this valid JSON" is not the question you actually have. It is a separate specification with its own versions, not part of RFC 8259, and adopting it is a deliberate choice.
JSON Lines, also called NDJSON, is one JSON document per line. It exists because a single JSON text is one value, which makes a growing log file impossible to represent; one object per line is appendable and streamable instead.
JSON Patch and JSON Merge Patch describe changes to a document rather than the document itself, which is what a well-behaved HTTP PATCH request carries.
JSON Pointer and JSONPath are ways of naming a location inside a document — the former standardised, the latter a widely-implemented convention with variations between implementations. The path finder implements dotted-path traversal in that spirit.
JSON-LD adds a vocabulary layer so a document can say what its fields mean, which is how search engines read structured data on a page.
None of these are things a JSON parser knows about. They are agreements between producer and consumer, which is exactly the gap ECMA-404 leaves open by design.
Working with JSON on this site
ToolForge has a dozen JSON tools, all of which run in your browser — which matters more here than for most formats, because a real payload usually contains a bearer token, a customer record or an internal identifier that has no business being uploaded to a stranger's server.
Where to start depends on what you have:
An unreadable wall of minified JSON. The formatter indents it, highlights it, and offers a collapsible tree view for finding your way around something deeply nested. How formatting works and what it changes covers the detail.
Something a parser rejected. Every error message, and what each one means is organised by the message you are actually looking at. For a deliberate pre-flight check instead, see how to validate JSON.
A question about what is legal. The syntax reference has the value types, the escape table and the grammar rules in lookup form.
A string that needs to survive being embedded. Escaping, explained — with the nesting case that catches everyone.
A format that is not JSON yet. Converters for YAML, XML and CSV, each of which loses something in the crossing; the tool pages say what.
JSON Formatter
Format, validate, and beautify JSON online. It runs in your browser, so the files never leave your machine, and there is nothing to install or sign up for.
Try the JSON FormatterFrequently asked questions
What does JSON stand for?
JavaScript Object Notation. The name is historical rather than descriptive — the syntax was taken from JavaScript object literals, but JSON is language-independent and is read and written by every mainstream language. Nothing about using it implies JavaScript anywhere in your stack.
Is JSON valid JavaScript?
Almost, and the gap has narrowed. Since a change to the ECMAScript specification, every valid JSON text is also a valid JavaScript expression. The reverse is emphatically untrue: JavaScript object literals allow unquoted keys, single quotes, trailing commas, comments and functions, none of which JSON permits. Pasting a JavaScript object into a JSON parser is the single most common reason one fails.
What is a .json file?
A plain text file containing one JSON document, conventionally UTF-8 encoded. There is nothing binary or special about it — you can open it in any text editor. The extension is a convention for humans and tools; the parser cares only about the contents.
Is JSON case-sensitive?
Yes, in two ways. Object keys are case-sensitive strings, so "userName" and "username" are different members. And the three literals must be lowercase: True, NULL and FALSE are all syntax errors, which catches people arriving from Python, where the equivalents are capitalised.
How big can a JSON file be?
The specification sets no limit; your parser and your memory do. Because a JSON document is one syntactic unit, most parsers read the whole thing before giving you anything, so files in the hundreds of megabytes become impractical. At that size, newline-delimited JSON or a columnar format is the better answer.
The short version
JSON is six value types and a short grammar, standardised twice, deliberately silent about meaning. That minimalism is why it is everywhere and also where its sharp edges are: no comments, no dates, no binary, and numbers that only behave up to about fifteen digits. Learn those four gaps and the format holds no further surprises — the remaining difficulty is always in the data, not the syntax.
Tools that go with this
Each one is here for a specific reason rather than because it is in the same category.
JSON Parse Tool
Parse JSON strings into JavaScript objects
Parses a string and re-serialises it, which is the quickest way to see what a parser actually made of your data.
JSON Escape / Unescape
Escape and unescape JSON strings
For the moment you need JSON inside JSON, or inside a shell command, and the quotes stop cooperating.
YAML ↔ JSON Converter
Bidirectional YAML and JSON conversion with error reporting
Moves between JSON and the format most configuration files are written in.
JSON to CSV Converter
Convert JSON data to CSV format
When the person who needs the data would rather have a spreadsheet than an array of objects.
JSON Diff Comparator
Compare two JSON files and find differences
Compares two payloads structurally, so reordered keys do not register as changes.
Related articles
JSON Syntax Reference
Every JSON syntax rule in one place: the six value types, the escape sequences, what numbers may contain, and the rules people think exist but do not.
How to Format JSON
Turn minified JSON into something readable, or the reverse. What formatting changes about your data, what it silently normalises, and when to minify.
Why Your JSON Is Invalid — Every Error Explained
Match the parser error to its cause: unexpected token, unexpected end of input, bad control character, and the invisible BOM. With the fix for each.
JSON vs XML: Which Should You Use?
JSON is smaller and easier to parse; XML carries attributes, namespaces and real validation. Where each one wins, and why the choice is rarely close any more.
JSON vs YAML: What Is the Difference?
YAML is JSON with comments, less punctuation and more ways to shoot yourself. What differs, why config chose YAML, and the traps in converting between them.
How to Validate JSON
Validating JSON answers three different questions: is it well-formed, does it match a schema, and is the data right. How to check each, and where each stops.
How to Escape Strings in JSON
Escaping JSON is easy until there are layers. How to escape a string, how to nest JSON inside JSON, and how to get a payload through a shell intact.
Sources
- RFC 8259 (STD 90) — The JavaScript Object Notation (JSON) Data Interchange Format
IETF · Standards organisation · published 1 December 2017 · accessed 7 September 2026
Cited for: Duplicate names SHOULD be unique, ordering not exposed consistently, the 2^53 interoperable integer range, and a JSON text being any serialized value
- ECMA-404, 2nd edition — The JSON Data Interchange Syntax
Ecma International · Standards organisation · published 1 December 2017 · accessed 7 September 2026
Cited for: That the standard defines syntax only and deliberately provides no semantics or interpretation
- JSON.parse() — JavaScript reference
MDN Web Docs · Technical documentation · accessed 7 September 2026
Cited for: Which JavaScript object-literal syntax a JSON parser rejects, and the SyntaxError it raises
About the author
Builder and maintainer, ToolForge
Started ToolForge in May 2026 and has built and maintained it since, writing every tool on the site and the documentation that goes with each one.
Part of
JSONWhat JSON is, the syntax rules that actually trip people up, why a parser rejected your file, and how JSON compares with XML and YAML.
Browse all developer tools