Guides / Concepts explained

What Is JSON? A Plain-English Guide with Examples

JSON is the simple text format apps use to send and store data. Learn its six value types, how to read it, common errors and how it shows up when you build.

Mythex Team · 2026-09-29 · 4 min read

JSON (JavaScript Object Notation) is a simple text format for writing down structured data — things like a customer, an order or a list of products — as names paired with values. It's easy for people to read and easy for programs to produce and parse. When apps and services exchange data over the web, JSON is by far the most common format.

Why JSON matters when you build with AI

You'll meet JSON constantly, even if you never write code:

• APIs. When your app's screens load data from its backend, or your backend calls a payment, email or AI service, the data usually travels as JSON. See what an API is.
• Settings files. Many project configuration files are JSON — for example package.json, which lists a JavaScript project's dependencies.
• Databases. Postgres can store JSON in a column (the jsonb type) for data that doesn't fit neat rows and columns. See what Postgres is.
• AI output. When you want an AI model to return something a program can use — a list of tags, extracted invoice fields — you usually ask for JSON.
• Error messages and logs. Many errors arrive as JSON, and reading them is often the fastest way to find out what went wrong.

Being able to read JSON lets you check what your app actually received, spot a missing field and describe problems precisely to your AI builder.

An everyday analogy

Think of a paper form: Name: ____, Phone: ____, Newsletter: ☐ yes ☐ no. Every entry is a label with a value next to it. JSON is that form written as text, in a strict layout a computer can read without guessing. And like forms, JSON can have sections within sections (an address block with street, city and postcode) and lists (several phone numbers).

What JSON looks like

Here's a single booking in JSON:

{
  "id": 5001,
  "customer": "Lena Park",
  "service": "Haircut",
  "startsAt": "2026-10-03T14:00:00Z",
  "price": 35.5,
  "paid": false,
  "notes": null,
  "extras": ["beard trim", "hot towel"],
  "contact": {
    "email": "lena@example.com",
    "phone": "+44 20 7946 0000"
  }
}

Reading it:

• Curly braces { } wrap an object — a set of name/value pairs.
• Each pair is "name": value, separated by commas.
• Square brackets [ ] wrap an array — an ordered list.
• Objects and arrays can sit inside each other, as contact and extras do.

The six kinds of value

JSON only has six types of value. That small list is a big part of why it works everywhere.

There's no date type. Dates are written as strings, usually in the ISO 8601 format shown above (2026-10-03T14:00:00Z, where Z means UTC). Agreeing on that format avoids a whole category of time-zone bugs.

The strict rules (where errors come from)

JSON is less forgiving than it looks. These are all invalid:

{ name: "Lena" }            ← key without double quotes
{ 'name': 'Lena' }          ← single quotes
{ "a": 1, "b": 2, }         ← trailing comma
{ "a": 1 "b": 2 }           ← missing comma
{ "a": 1 // comment }       ← comments aren't allowed

Most "Unexpected token" errors you'll see are one of these. A JSON validator or formatter will show you the exact line.

A worked example: JSON through an app

A customer books a haircut in a salon app. Here's where JSON appears:

1. The booking form sends this to the app's backend:

{ "service": "Haircut", "startsAt": "2026-10-03T14:00:00Z", "name": "Lena Park" }

1. The backend saves the booking in the database and replies with status 201 Created and:

{ "id": 5001, "status": "confirmed" }

1. If the time was already taken, it might instead reply with status 409 Conflict and:

{ "error": "slot_taken", "message": "That time was just booked. Please pick another." }

The page reads status or error and shows the right message. If the page showed a blank screen instead, opening the browser's developer tools (Network tab) would show you this JSON — often the quickest clue to what went wrong.

Key terms

Common misconceptions

• "JSON is JavaScript." It came from JavaScript's syntax, but it's language-independent; Python, Java, C#, Go and the rest all read it.
• "Numbers in quotes are fine." "35" is a string, not a number. Mixing them causes bugs like "35" + "5" becoming "355". Money is often better stored as whole cents (3550) to avoid rounding issues.
• "JSON is secure because it's just data." JSON can carry anything, including secrets. Don't put API keys in JSON that's sent to the browser.
• "Put everything in a JSON column." Handy for flexible extras, but data you search, filter or join on usually belongs in proper columns.
• "The AI always returns valid JSON." Models can add extra text or break the format. Many providers offer a structured-output mode; your code should still check what comes back.

What to ask your AI builder

• "Show me an example of the JSON this endpoint returns."
• "Return errors as JSON with an error code and a human-readable message."
• "Store dates as ISO 8601 strings in UTC and convert to local time only on screen."
• "Store prices as integer cents."
• "Validate incoming JSON on the server and reject requests with missing or wrong-typed fields."
• "When calling the AI model, ask for JSON in this exact shape and check it before using it."

JSON in Mythex

You don't need to write JSON by hand in Mythex — you describe what you want and the agent writes the code that sends and reads it. It helps to recognise it, though: when something breaks, pasting the JSON error into chat gives the agent a precise clue. The docs' REST API backend recipe asks for "clear JSON errors" from the start, and the integrate any API recipe covers calling outside services. For the bigger picture, see REST vs GraphQL and how to debug an AI-built app.