JSON: The Data Format Apps Share

Before You Study (5 mins)

Lesson focus: Whether it's a tweet, a bank balance, a weather report, or a social-media feed, almost all data exchanged between apps on the modern internet travels in one format: JSON. If you can read JSON fluently, you can read the wire-format of essentially every modern API, configuration file, and database export. Today we go past the "JSON is curly braces" framing and into the exact specification — six data types, the parsing rules every parser implements, and the footguns that bite even senior engineers.

What you should have ready:

• VS Code from Lesson 02 — we'll write JSON files
• Terminal fluency from Lesson 04 — we'll use node to parse JSON
• Your Snake game project — we'll move its settings into a config.json
• A browser open to your game's page — we'll inspect API JSON in DevTools
• About 50 minutes

The Concept

JSON stands for JavaScript Object Notation. The name is misleading: JSON is a data format, not a programming language, and is supported natively by every major language (Python, Java, Go, Rust, C#, PHP, Ruby, Swift). It was extracted in the early 2000s from JavaScript's literal syntax for objects and arrays, formalized as ECMA-404, and won the wire-format war over XML through one quality: it is small enough to transmit cheaply, and human-readable enough to debug without tools.

The entire JSON specification fits in your head. There are exactly six data types:

That is the entire data model. There is no "date" type (you encode dates as ISO 8601 strings: "2026-04-29T14:30:00Z"). There is no "binary" type (you encode binary as Base64 strings, which adds ~33% overhead — a real consideration for images and large blobs). There is no separate integer type (large integers above 2⁵³ lose precision in JavaScript — a notorious footgun for finance and timestamp APIs).

The gotchas every JSON-handling engineer hits are worth memorizing once:

• No comments allowed. A // note in your JSON file makes it invalid. (Some tools support a "JSON with comments" variant — tsconfig.json, .vscode/settings.json — but pure JSON parsers reject them.)
• No trailing commas. [1, 2, 3,] is invalid. The final element cannot have a comma after it.
• Keys must be strings. {"42": "answer"} is valid; {42: "answer"} is not.
• Strings must use double quotes. Single quotes are invalid. 'hello' will fail.
• No undefined. JavaScript's undefined is not a JSON value. Serializing {a: undefined} drops the key entirely.

The two things JSON does that you'll actually use in this lesson are serialize (turn a JavaScript object into a JSON string) and deserialize (parse a JSON string back into an object):

const settings = { speed: 10, color: "#22D3EE", arena: "neon" }
const text = JSON.stringify(settings)        // serialize
const back = JSON.parse(text)                // deserialize

Once these two functions click, every API call, every config file, every cross-process message becomes legible.

The reason JSON beat XML for the wire format is partially historical and largely practical. A JSON payload is roughly 30-50% smaller than the equivalent XML for the same data because JSON has no closing tags (XML's <name>...</name> becomes JSON's "name": ...). It parses in less code because the data model maps directly onto JavaScript object literals — and most other languages have followed suit. XML's strengths — namespaces, attributes, schema-inline expressiveness — turn out to matter most for document markup (which is what XML was designed for) and less for the data-interchange use case that came to dominate web traffic.

The deeper reason JSON is durable is composability. A JSON document can contain other JSON documents nested arbitrarily — an array of objects, where each object contains another array, where each item is a string. The same recursive structure encodes a tweet, a directory listing, a database row, a configuration tree, a serialized React component state, a Kubernetes manifest. Once you internalize the six types and the recursion, every JSON document on the internet becomes the same document with different content.

Want the longer story — why JSON beat XML, JSON Schema for validation, JSON-LD for semantic data, and the binary alternatives like Protobuf? The companion article What is JSON and Why Does Every Application Use It is the definitive reference. Read it after this lesson for the historical and architectural context.

Quick Concepts

What We Will Build

By the end of this lesson, you will have done these specific things:

1. Created a new file config.json in your Snake game project with your game settings:
   json

   Copy

   {
     "gameName": "Super Snake",
     "speed": 10,
     "snakeColor": "#22D3EE",
     "arenaColors": ["#0B0C15", "#151621"],
     "is3D": true,
     "highScores": []
   }
   

2. Validated your file is well-formed JSON. In the terminal: node -e "console.log(JSON.parse(require('fs').readFileSync('config.json','utf-8')))". If your file has a typo, the error message will tell you the line and column.
3. Modified your game code to read config.json at startup instead of hardcoding the speed and color. Confirmed the game uses the values from the file.
4. Changed speed from 10 to 25 in the JSON, reloaded the game, watched the snake move faster — without touching .js code.
5. Triggered each common JSON parsing error on purpose (so you recognize them when they bite later):
   • Add a trailing comma after "highScores": []. Reload. Watch the parser refuse.
   • Use a single quote: 'gameName': "Super Snake". Reload. Watch the parser refuse.
   • Add a // comment line. Reload. Watch the parser refuse.
   • Fix all three; confirm valid again.
6. Opened your browser's DevTools (F12 or Cmd+Option+I), Network tab, and inspected the response of any API call your game (or the page) makes. Recognized that everything coming back is JSON.

The point of step 5 is the most important. Hitting each error intentionally once is the fastest way to recognize them when they appear by accident later.

Think About

Before studying, consider:

1. Two systems written in different languages — say, a Python backend and a JavaScript frontend — need to exchange a list of users. Without JSON (or a similar format), how would they agree on what a "user" looks like over the wire? (Hint: every other approach involves much more code.)
2. JSON allows nested structures arbitrarily deep. Why is "an array of objects, each with an array of objects" a normal data shape, while "a 7-deep nested object" is usually a code smell? Where is the line?

By the End

After this lesson, you'll:

• ✅ Know all six JSON data types by heart
• ✅ Have a working config.json driving your game's settings
• ✅ Have intentionally triggered the four common JSON errors so you recognize them later
• ✅ Be able to read JSON in DevTools' Network tab and understand what you're looking at
• ✅ Know what JSON.stringify and JSON.parse do
• ✅ Be ready to call APIs in Lesson 09 — because every API response is JSON

The format that runs the data side of the web. Six types and you read it all. 💬

What We Learned

• JSON has exactly six data types: object, array, string, number, boolean, null. The whole specification fits in your head.
• JSON beat XML for the wire format because it is smaller, faster to parse, and readable without tools — even though XML can express things JSON cannot (attributes, namespaces, schemas inline).
• The two operations every engineer uses constantly are JSON.stringify(obj) (serialize) and JSON.parse(text) (deserialize). Master these and most data-handling code reads as obvious.
• The four most common errors: trailing commas, single quotes, comments, and undefined values. Trigger each once on purpose so you recognize them when they bite by accident.
• JSON is text. It can be saved to a file, sent over HTTP, stored in a database column, copy-pasted between programs. This portability is why it won.
• Configuration as JSON is the simplest way to change app behavior without changing code — exactly what we did with config.json for the Snake game.

Commands We Used

# Validate a JSON file from the command line — fastest way to check syntax
node -e "JSON.parse(require('fs').readFileSync('config.json','utf-8')); console.log('valid')"

# Pretty-print JSON so it's readable
node -e "console.log(JSON.stringify(JSON.parse(require('fs').readFileSync('config.json','utf-8')), null, 2))"

# Use the `jq` tool — the unix command-line JSON processor (install: brew install jq)
jq . config.json                          # pretty-print
jq '.speed' config.json                    # extract one field
jq '.arenaColors[0]' config.json           # extract first item of an array
jq 'keys' config.json                      # list top-level keys

The two functions every JavaScript developer uses constantly:

// Serialize: object -> JSON text
const settings = { speed: 10, color: "#22D3EE", is3D: true }
const text = JSON.stringify(settings)
// → '{"speed":10,"color":"#22D3EE","is3D":true}'

// Pretty version for human reading: 2-space indent
const pretty = JSON.stringify(settings, null, 2)
// → multi-line, indented version

// Deserialize: JSON text -> object
const back = JSON.parse(text)
console.log(back.speed)                    // 10

// In a real app — load config from a file (Node)
import { readFileSync } from 'node:fs'
const config = JSON.parse(readFileSync('config.json', 'utf-8'))

// In a browser — load config from the network
const config = await fetch('/config.json').then(r => r.json())

The four common errors and how parsers report them:

SyntaxError: Unexpected token } in JSON at position 154   ← trailing comma
SyntaxError: Unexpected token ' in JSON at position 12    ← single quote
SyntaxError: Unexpected token / in JSON at position 0     ← comment line
TypeError: Converting circular structure to JSON          ← stringify on a cyclic object

Why It Matters

Every API call your phone makes today returns JSON. The settings file your code editor reads is JSON. The package.json that defines your project's dependencies is JSON. The configuration of every cloud service is, almost without exception, JSON or its strict-superset YAML. The wire format of one of the technologies you'll use in Module D — calling an LLM API to add AI features to your game — is JSON request, JSON response.

This means JSON fluency compounds. Every other web technology you'll touch in this course assumes you can already read it. APIs (Lesson 09) send and receive JSON. The full-stack work in Module C uses JSON to move data between frontend and backend. The AI integration in Module D uses JSON to structure prompts and parse responses.

The deeper insight is schema: JSON itself only enforces syntax (is the text well-formed?), not meaning (does this look like what my app expects?). For production APIs, you layer JSON Schema on top — a separate document declaring "this object must have a name (string), age (number ≥ 0), email (matching pattern X)". The schema becomes the contract; the API server validates incoming data against the schema; client SDK code is generated from the schema. This is how serious APIs maintain compatibility across versions.

What we glossed over but you'll meet:

• JSON Schema for validation contracts — ajv is the standard JavaScript validator.
• JSON-LD for semantic data — search engines use it (the BlogPosting JSON-LD on every blog post is what helps Google understand the content).
• Binary alternatives — Protobuf, MessagePack, BSON — used inside high-performance systems where the size and parse speed of JSON become bottlenecks. JSON is the lingua franca; binary formats are the optimization.
• Streaming JSON parsers — for very large files where you can't fit the whole document in memory. Real, but rare.

Want the full story including JSON-LD, the precision wall on integers above 2⁵³, and why the Base64-binary tradeoff matters for image-heavy APIs? Read What is JSON and Why Does Every Application Use It — calibrated to extend exactly what you just practiced.

Checklist

• I created config.json with at least 5 game settings
• I validated the file with node -e "JSON.parse(...)" — got "valid" output
• My game now reads settings from JSON instead of hardcoded values
• I changed a setting in JSON, reloaded, watched the game update
• I triggered all 4 common errors on purpose (trailing comma, single quote, comment, malformed)
• I opened DevTools' Network tab and saw real JSON responses from a real API
• I can name the 6 JSON data types from memory

Quick Quiz

Q1: How many data types does JSON have, total?

• A) Three
• B) Six — object, array, string, number, boolean, null ✓
• C) Twelve

Q2: Which of these is NOT valid JSON?

• A) [1, 2, 3]
• B) {"name": "Snake", "speed": 10}
• C) {name: 'Snake', speed: 10,} ✓ (single quotes, unquoted key, trailing comma — three errors)

Q3: What does JSON.stringify(obj) do?

• A) Validates that the object is well-formed
• B) Turns an in-memory object into a JSON text string ✓
• C) Encrypts the object

Q4: What's the precision limit on JSON numbers in JavaScript?

• A) There is no limit
• B) Above 2⁵³, integer precision is lost (JavaScript uses double-precision IEEE 754 floats) ✓
• C) The limit is 2³²

Q5: Why are there no comments allowed in JSON?

• A) The original spec deliberately omitted comments to keep parsers simple ✓
• B) Comments would be a security risk
• C) JSON has comments — they use #

Bonus Challenge

Add a cheatMode boolean to your config.json. When true, the snake should be invincible (won't die from collision). Read the value at game start; pass it as a flag into your collision-detection logic. The point of this exercise is to feel how a single boolean in a config file flows through code paths — exactly the pattern feature flags use in production systems.

Next Lesson

Lesson 09: How Apps Talk — APIs Revealed

You'll learn: Your game now reads JSON files. The next step is asking another computer for JSON over the network — calling a public API, parsing the response, using the data. The HTTP request-response cycle, the verbs that matter, status codes as a protocol.

JSON is the language of data. You speak it now. 💬