What JSON actually looks like
JSON (JavaScript Object Notation) is a text format for structured data built from key-value pairs, and almost every web API speaks it. A typical record looks like this: {"name": "Asha", "age": 29, "member": true}. Keys are always double-quoted strings, values can be strings, numbers, booleans, arrays, objects, or null, and the whole document is plain text.
You meet JSON everywhere: REST API responses, configuration files like package.json, saved app settings, and dashboard data exports. Because it is plain text with a strict grammar, both humans and machines parse it easily — but that strictness means one misplaced comma breaks the entire document.
Objects, arrays, and the six data types
JSON has exactly six data types: string, number, boolean, null, object, and array. Objects hold named keys in curly braces and arrays hold ordered lists in square brackets. A realistic order shows the pattern: {"orderId": 4128, "paid": true, "coupon": null, "items": [{"sku": "MUG-01", "qty": 2}]}. Note that 4128 has no quotes, true is lowercase, and null marks the empty coupon.
Three type rules trip up beginners. First, there is no date type — dates travel as ISO strings like "2026-09-17T10:30:00Z". Second, numbers cannot have leading zeros, so PIN codes and phone numbers belong in strings. Third, strings must use double quotes with backslash escapes — single quotes are never valid in JSON.
- Six types only: string, number, boolean, null, object, array
- Objects for named fields, arrays for ordered lists; nest them freely
- Dates are ISO strings; phone numbers and PINs are strings, not numbers
How to format and validate JSON
Formatting means pretty-printing minified JSON so humans can read it: a one-line API response becomes indented with two spaces per level. Validation means parsing the document strictly and reporting the first syntax error with a line and column number. A JSON formatter gives you both at once — readable structure plus a verdict with the exact failure point highlighted.
Validate at three moments: when you first receive an API response, before saving a hand-edited config file, and when a fetch call throws a parse error. Fix the reported error, revalidate, and repeat until the parser is happy — then minify for production if size matters.
Five syntax errors and how to fix each one
The trailing comma is the most common killer: {"a": 1,} fails because JSON forbids a comma after the last item — delete it. Next come single quotes: replace them with double quotes. Third, unquoted keys like {name: "Asha"} must become {"name": "Asha"}. Fourth, comments are illegal in strict JSON — strip them before validating.
The fifth error is trailing content after the top-level value, such as two objects pasted back to back. Wrap them in an array to fix it. When a validator reports an unexpected token at some line and column, look just before that spot — the real culprit is usually a missing comma, quote, or bracket.
- {"a": 1,} fails — remove the trailing comma after the last item
- Single quotes fail — JSON requires double quotes everywhere
- Unquoted keys fail — every key must be a double-quoted string
- Comments are illegal — remove them or use a JSONC-aware parser
JSON meets Base64 and UUIDs in real APIs
Real payloads often embed binary data as Base64 text inside a JSON string, because JSON cannot carry raw bytes. The word "Hi" encodes to "SGk=" — the trailing = is padding to a multiple of four characters. If that string is corrupt, the JSON still validates but the decoded file breaks, so decode the Base64 separately to isolate the problem.
Unique identifiers ride along the same way: every order or user gets a UUID v4 such as "550e8400-e29b-41d4-a716-446655440000" — 32 hex digits in an 8-4-4-4-12 pattern. Generate a fresh UUID per request, never reuse one across orders, and store it as a plain JSON string your database can index.
- "Hi" encodes to "SGk=" — real Base64 with padding, safe inside JSON strings
- UUID v4 pattern is 8-4-4-4-12 hex digits, generated fresh per request
- Validate the JSON first, then decode Base64 and UUID fields separately
Mistakes beginners make with JSON
The costliest mistake is hand-editing a long config and deploying without validating — one dropped comma can take down a whole service. Developers also store phone numbers as numbers, corrupting values with leading zeros and plus signs; wrapping identifiers in quotes from day one avoids a painful migration.
Formatting mistakes compound the pain: committing minified one-line JSON hides diffs in code review, and building JSON with string templates produces unescaped quotes the moment a name contains an apostrophe. Pretty-print before saving and always build payloads with JSON.stringify.
- Validate hand-edited configs before deploying — one comma can cause an outage
- Store phone numbers, PINs, and IDs as strings, never as numbers
- Build JSON with JSON.stringify, not string concatenation
JSON questions beginners always ask
Is JSON the same as a JavaScript object? Almost but not quite — JSON is strict text with double-quoted keys, no functions, and no comments. JSON.parse converts the text into a real object, and JSON.stringify converts it back. Think of JSON as the shipping box and the JavaScript object as the contents.
Is there a size limit? The format has none, but responses above a few megabytes slow parsing on phones — paginate large lists and request only needed fields. And remember that validators check syntax only, so confirm field names against the API docs after the syntax passes.
- JSON is strict text; parse and stringify to convert to live objects
- Paginate past a few MB for speed and memory on mobile
- Validators check syntax, not meaning — verify fields against API docs