JavaScript Object Notation (JSON) is a lightweight text format for structured data. A JSON document is built from objects (sets of named values inside curly braces) and arrays (ordered lists inside square brackets), holding strings, numbers, true, false or null. Although its syntax came from JavaScript, JSON is independent of any programming language. It is a common format for web APIs, webhooks and many log and export files, so many integrations a business buys will send or receive JSON.
At a glance
- JSON represents data as named values (objects) and lists (arrays) in plain text.
- It supports a small set of types: string, number, boolean, null, object and array.
- It is a common format for REST APIs and webhooks.
- Standard JSON has no comments, which keeps it strict and simple for machines to parse.
- It is defined in published standards from Ecma International and the IETF.
What problem it solves
When two systems exchange data, they need to agree on its shape. A CRM sending a new customer record to a billing system has to say which part is the name, which is the email and which is the account number. Before JSON became common, many integrations used XML, fixed-width files or vendor-specific formats, which were verbose or fragile.
JSON gives both sides a simple, shared structure. Each value has a name, nesting shows which values belong together and lists hold repeated items, such as order lines. Most programming languages have a built-in or widely used parser, so developers can turn a JSON document into usable data in a few lines of code. That low friction is why JSON became the default for web APIs and for many configuration and logging formats.
How it works
Objects and arrays. An object is a set of "key": value pairs in curly braces. An array is a list of values in square brackets. Objects and arrays can be nested, so an order object can contain a customer object and an array of line items.
Strict syntax. Keys must be in double quotes, items are separated by commas and trailing commas are not allowed. There are no comments. This strictness means a parser either reads the document or rejects it, with little room for interpretation.
Types. JSON has no separate type for dates, money or binary data. Dates are usually sent as text in an agreed format, and large or precise numbers may need care, because some languages and tools handle very large integers or decimals differently.
Schemas and contracts. JSON itself does not say which fields must be present. API providers describe their payloads in documentation, JSON Schema or API description formats, and well-run integrations validate incoming data against them.
Where it shows up. APIs, webhooks, microservices, structured logs sent to log management tools, NoSQL databases, browser applications and some network management interfaces such as RESTCONF.
When it matters for buyers
- Integrations. If a vendor offers a web API, it is likely to use JSON. Ask for documentation and sample payloads before you sign, not after.
- Change management. Renaming or removing a field can break every integration that depends on it. Versioning and deprecation notice periods matter.
- Security. APIs that accept JSON are an attack surface, and web application and API protection tools inspect and validate those requests. See our web application and API protection page for help comparing providers.
- Logs and exports. Structured JSON logs are easier to search and correlate than free text, and many observability tools ingest them directly.
- Data portability. A full JSON export of your records is often the practical way to leave a SaaS platform.
Questions to ask vendors
- Is your API documented with sample JSON requests and responses, and is there a published schema?
- How do you version the API, and how much notice do you give before changing or removing fields?
- How are dates, currencies and large numbers represented in your JSON?
- Can we export all of our data as JSON or another documented format?
- What payload size and rate limits apply to API requests?
- Do your logs and webhook events use a consistent, documented JSON structure?
How it differs from XML
XML and JSON both carry structured data as text, but they come from different traditions. XML wraps each value in opening and closing tags, supports attributes, namespaces and mixed text and markup, and has mature schema languages for strict validation. That makes it suited to documents and to standards that need precise contracts, and it remains common in older enterprise integrations, identity standards and some network protocols. JSON is shorter, has fewer concepts and maps directly onto the objects and lists programmers already use, so it is a common choice for newer web APIs. YAML is the third common format: it represents the same kinds of data as JSON but is written for people, with indentation and comments, and is used mostly for configuration.